Announcement

Collapse
No announcement yet.

Improved Memory Security For Radeon DRM

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

  • #16
    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?

    Comment


    • #17
      Not third party patent applications, *our* patent applications

      It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.

      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.

      Next update will probably be when we find and fix the problem; might be today but I doubt it.

      Comment


      • #18
        Originally posted by bridgman View Post
        Not third party patent applications, *our* patent applications
        It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.
        Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?
        Good to know that r6xx-rewrite is moving forward . Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?

        Comment


        • #19
          Originally posted by ssmaxss View Post
          Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?
          We have already done that. The problem is that there are a number of different ways to use the hardware depending on which bits we can publicly expose first, so we need to get that sorted out before the devs can write anything more than prototype code.

          Originally posted by ssmaxss View Post
          Good to know that r6xx-rewrite is moving forward . Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?
          It's a core bug which should help in number of areas.
          Last edited by bridgman; 06-19-2009, 12:21 PM.

          Comment


          • #20
            Originally posted by Zhick View Post
            AFAIK ClockGating == DynamicClocks, it has just been renamed at some point to reflect more clearly what it does.
            thanks !

            I just saw it in the logs:

            Static power management enable success
            (II) RADEON(0): Dynamic Clock Gating Enabled
            (II) RADEON(0): Dynamic Power Management Enabled
            (II) RADEON(0): Force Low Power Mode Enabled
            (II) RADEON(0): Power Mode Switch
            Dynamic Clock Gating == Dynamic Clocks (old) == ClockGating (new)

            Comment


            • #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; 06-22-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.

                    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.

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

                            Comment

                            Working...
                            X