Page 1 of 2 12 LastLast
Results 1 to 10 of 16

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,646

    Default The Main DRM Pull Request For The Linux 2.6.37 Kernel

    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

  2. #2
    Join Date
    Feb 2009
    Location
    France
    Posts
    291

    Default

    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.

  3. #3
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote Originally Posted by MPF View Post
    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.

  4. #4
    Join Date
    Feb 2009
    Location
    France
    Posts
    291

    Default

    Quote Originally Posted by droidhacker View Post
    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?

  5. #5
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    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?

  6. #6
    Join Date
    May 2008
    Posts
    14

    Default

    Quote Originally Posted by RealNC View Post
    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?

  7. #7
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    Quote Originally Posted by RealNC View Post
    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.

  8. #8
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

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

  9. #9
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,578

    Default

    Quote Originally Posted by RealNC View Post
    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.

  10. #10
    Join Date
    Jan 2010
    Posts
    159

    Default

    Quote Originally Posted by RealNC View Post
    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?!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •