Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Improved Memory Security For Radeon DRM

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,123

    Default Improved Memory Security For Radeon DRM

    Phoronix: Improved Memory Security For Radeon DRM

    Yesterday the TTM memory manager and Radeon kernel mode-setting code entered the mainline Linux kernel Git tree, which means it will be part of the next Linux 2.6.31 kernel release. In the 2.6.31 series this new Radeon driver will be marked as "staging" as there is still some work left to be accomplished and further testing needs to be done with this driver and different Radeon graphics cards...

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

  2. #2
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    Dear Phoronix,

    Can you please link to some mail archive other than the abomination that is sourceforge? Much appreciates - an anonymous user.

    Personally, I find gmane to be much more readable. and faster.

  3. #3
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    258

    Default

    Seconded. Gmane is so much easier to read, sourceforge could only be the worst choice for a link.

    Edit: adding the link:
    http://article.gmane.org/gmane.comp....ri.devel/36435
    Last edited by susikala; 06-18-2009 at 02:06 PM.

  4. #4
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Couldn't be bothered looking for it in gmane, but here you go:
    http://www.mail-archive.com/dri-deve.../msg40780.html

  5. #5
    Join Date
    Sep 2008
    Posts
    332

    Default

    when can we expect kms for r600-r700 to enter the kernel?

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    The pacing item here is memory management for 6xx-7xx. We may need to release some additional HW info in order to finish memory management (specifically interrupts), not sure but looking into it.

    It's probably safe to say "either 2.6.31 or 2.6.32" but hard to be more precise.

  7. #7
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    640

    Default

    it's very subjective which parts should be developed earlier:

    for me it's definitely not KMS

    any info when additional power management support or improvements will be added to the xf86-video-ati or radeonhd driver ?

    currently my box is getting warmer several degrees (centigrade) which also implies higher power consumption compared to fglrx/catalyst, for several people there's also the problem of fast spinning fans which is unacceptable

    I know that 3D surely still takes a while for R600 or R700 but at least proper power management should be there

    (even without DRI it's already faster than fglrx during 2D operations )

    thanks

  8. #8
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    We may need to release some additional HW info in order to finish memory management (specifically interrupts), not sure but looking into it.

    It's probably safe to say "either 2.6.31 or 2.6.32" but hard to be more precise.
    Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by ssmaxss View Post
    Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.
    No ETA on the doc yet; I'm just checking status of patent applications.

    What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.

    Hardware enablement is always a bit different from other driver/kernel enhancements, since if it's done right the chance breaking existing functionality is essentially zero and the worst that would happen is that the code has problems on some of the new hardware - vs not working at all before. It's one of those "on the fence" cases we'll need to deal with more now that core graphics support is moving into the kernel just like all the other hardware.

  10. #10
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.
    So there is a chance that you can't release docs for interrupts due to some 3rdparty IP, and they are needed to make MM "nice" and OSS drivers end up with crippled MM?
    BTW: will we see Friday code drop for r6xx-rewrite today?

Posting Permissions

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