Announcement

Collapse
No announcement yet.

Improved Memory Security For Radeon DRM

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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>

    Comment


    • #22
      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; 22 June 2009, 11:12 AM.

      Comment


      • #23
        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)

        Comment


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

          Comment


          • #25
            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...

            Comment


            • #26
              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.
              Test signature

              Comment


              • #27
                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.

                Comment


                • #28
                  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...
                  Test signature

                  Comment

                  Working...
                  X