The Main DRM Pull Request For The Linux 2.6.37 Kernel

[agd5f]

Display watermarks? Like the "unsupported" watermark of fglrx?

not exactly

Display watermarks control the display fifos and their priority in the memory controller. If it's not set up properly, you can get underflow to the display controller: the data from the memory controller doesn't arrive in time causing the fifo to run dry leading to flickering or other display artifacts.

[bridgman]

Watermarks are like DRM. There are good ones and bad ones.

These watermarks are FIFO tuning parameters (imagine the FIFO being oriented vertically and your display data leaving stains on the side of the FIFO ).

[curaga]

Display watermarks? Like the "unsupported" watermark of fglrx?

[Lynxeye]

I am quite impressed with all the DRM progress. It just a tad frustrating that only a few distros that either use a rolling release model like Arch or make it easy to compile your own kernel are able to provide users with some means of using an up-to-date kernel. I mean, F14 is not even out yet, but the kernel in it already seems dated in terms of graphics improvements, no?

You miss the point that Fedora ships a heavily patched kernel. Many of the upstream improvements in the mainline kernel are available in the Fedora kernel of older releases. And Fedora kernel gets rebased to upstream kernel in the lifecycle of one Fedora release.

So you get the improments like in a rolling release, sometimes you have to wait a litte longer, but in many cases you get it actually earlier than with mainline kernel.

[korpenkraxar]

I am quite impressed with all the DRM progress. It just a tad frustrating that only a few distros that either use a rolling release model like Arch or make it easy to compile your own kernel are able to provide users with some means of using an up-to-date kernel. I mean, F14 is not even out yet, but the kernel in it already seems dated in terms of graphics improvements, no?

[bridgman]

I see. After the UMS->KMS thing, I thought with KMS most stuff happens in the kernel :P

KMS only really moved modesetting and memory management. The 2D, 3D and video acceleration code all stayed in user space.

[Ragas]

I see. After the UMS->KMS thing, I thought with KMS most stuff happens in the kernel :P

So, don't you think it's a good thing if most things are done in kernel now .... and all those things are already done?!

[nanonyme]

I see. After the UMS->KMS thing, I thought with KMS most stuff happens in the kernel :P

I think Linus would have had a few objections if it was like that.

[RealNC]

I see. After the UMS->KMS thing, I thought with KMS most stuff happens in the kernel :P

[agd5f]

It's been many months since the 2.6.36 merge window closed, and ALL that was accomplished in that time on the Radeon side is:

"introduce new fences on R600 ASICs and newer, spread spectrum improvements on R500 and newer, Radeon HD 5000 series blit support, PLL fixes, and a number of tiling fixes."

Why is development moving so excruciatingly slow? At that pace, we will never, ever get rid of fglrx. It will still be the premium performance choice for years to come.

What is happening? Is anything stalling the development?

It also included display watermark support for evergreen. Barring support for new asics, there's not much else that needs to be done in the drm. Most new "feature" improvements are part of mesa which has seen a lot of updates.