The Main DRM Pull Request For The Linux 2.6.37 Kernel

[phoronix]

Phoronix: The Main DRM Pull Request For The Linux 2.6.37 Kernel

David Airlie has just called upon Linus Torvalds to pull in his DRM kernel tree for the Linux 2.6.37 kernel merge window. We have talked about many of these features before that are now entering the mainline Linux kernel code-base as new capabilities of the open-source Linux graphics stack, but here's the list of what made the cut for Linux 2.6.37 and details on some of the features we have yet to discuss...

http://www.phoronix.com/vr.php?view=ODcyNA

[MuPuF]

Sorry to say that, but Power management won't be "supported" on nouveau.

It may "work", but we don't expect it to work nicely for anyone.

You'll have to wait until Linux 2.6.38 before you get something half-way working. There is so much work to be done.

[droidhacker]

Sorry to say that, but Power management won't be "supported" on nouveau.

It may "work", but we don't expect it to work nicely for anyone.

You'll have to wait until Linux 2.6.38 before you get something half-way working. There is so much work to be done.

I think that he means that there will be... initial experimental support for [some] power management features.

[MuPuF]

I think that he means that there will be... initial experimental support for [some] power management features.

Exact Hopefully, we'll get a minimal but safe power management soon.

So far, the blob does a lot more than just changing the clocks. So, laptop users, don't expect too much gains in autonomy.

On the other hand, some people (like me) have their GPU under-clocked by default, this means PM will get them a nice performance improvement.

One feature that should also be included in the 2.6.38 is the pageflip API. Some users get up to 5 times more FPS (in open arena) on nv4x. Sounds good doesn't it?

[RealNC]

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?

[gentoofu]

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?

There's quite of work going on the Mesa side. Is that not good enough for you?

[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.

[RealNC]

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

[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.

[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?!