Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: Improved Memory Security For Radeon DRM

  1. #21
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,595

    Default

    Quote Originally Posted by bridgman View Post
    Not third party patent applications, *our* patent applications
    <minor troll>Now, that sounds something that would be a *lot* simpler with Solaris. There you could just grant them right to use the patent, kernel modules would be written using CDDL which recognizes AMD/ATi's patents and everyone would be happy. </minor troll>

  2. #22
    Join Date
    Mar 2008
    Posts
    14

    Default

    As I understand the problem here is not GPL vs patents. They don't want to describe this part of chip, because they haven't yet got patent for it (only patent applications)

    btw: as always, will be interesting to hear about any progress with r6xx-rewrite.
    Last edited by ssmaxss; 06-22-2009 at 11:12 AM.

  3. #23
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,595

    Default

    Quote Originally Posted by ssmaxss View Post
    As I understand the problem here is not GPL vs patents. They don't want to describe this part of chip, because they haven't yet got patent for it (only patent applications)
    Oh, right. It might well be a hardware patent. (which would go way beyond the scope of GPL's anti-patent agenda)

  4. #24
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Yes, any time I talk about patents with relation to providing programming info we're talking about hardware patents.

  5. #25
    Join Date
    Mar 2008
    Posts
    14

    Default

    Quote Originally Posted by bridgman View Post
    Richard tracked down the rendering problems with 6xx-rewrite last night to a problem in the new memory management code (in mesa, not in kernel); all we know right now is that if we bypass the memory manager the rest of the driver works.
    Any updates on this? Looks like last major commit to r6xx-rewrite was 12 days ago...

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

    Default

    Yeah, latest news (from a couple of hours ago) is that the problem is that we were adding the buffer offset twice; once in mesa and once in drm. Adding the offset in drm was a relatively recent change suggested to improve compatibility with the GEM/TTM scenario, but looks like we were still adding it in mesa as well. The fix should go into mesa AFAIK.

    There were some bug fixes in 6xx-rewrite a few days ago, but until the memory manager issue is fixed it's kinda hard to make progress on anything else.

  7. #27
    Join Date
    Mar 2008
    Posts
    14

    Default

    Cool. Is there a patch for that offset bug somewhere? Will this fix allow to enable clear code, that gives redbook hello background proper color?

    Is the term "memory manager" used to describe two different things in context of mesa driver (where it exists, but contains bugs) and KMS (where it doesn't exist)? e.g.: couldn't mesa's memory manager be reused for KMS purposes.

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    No patch yet; as soon as we have a fix it will get pushed into the public repo. All I know so far is that when Richard bypassed the memory management completely both clear and shader ops worked - what I don't know is whether this offset issue is the only problem we're having in the memory manager or just the first.

    I haven't had a chance to go through the code yet, but as I understand it the memory management code we're dealing with here (bufmgr/cs in mesa plus the correspoinding code in drm) is something similar to the old userspace memory management code but with an API much closer to the GEM/TTM implementation going into the kernel. It doesn't have all the capabilities of the GEM/TTM code in the kernel though...

Posting Permissions

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