Announcement

Collapse
No announcement yet.

AMD R600/700 DRM Interrupts Support Pushed

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

  • #31
    Cheers for the new specs and stuff.
    I only wish 2.6.33 was already here.

    Comment


    • #32
      Originally posted by agd5f View Post
      Only kms support interrupts for r6xx+.
      Is working being done to get UMS to support interrupts?

      Adam

      Comment


      • #33
        Originally posted by adamk View Post
        Is working being done to get UMS to support interrupts?
        No. Because of the way interrupts work on r6xx+ (another ring buffer in gart), it's not really easy to do with UMS without a lot of work in both the drm and ddx. With UMS the ddx initially allocates memory, so it would have to be updated to reserve a portion of the gart for the interrupt ring buffer then you'd need to add a mechanism to tell the drm about the new allocation, then you'd have to update the drm to set up and use the interrupt ring buffer. It's a lot of work for little gain.

        Comment


        • #34
          Originally posted by agd5f View Post
          It's a lot of work for little gain.
          Well I'd disagree. At least it would work for r6xx/r7xx across the board, in places where KMS is still not usable. But, then again, I'm not the one would be be doing the work :-)

          Comment


          • #35
            Originally posted by adamk View Post
            in places where KMS is still not usable.
            not sure what you mean, but wouldn't it be wiser to make KMS usable in those places instead of wasting time on outdated technologies?

            Comment


            • #36
              Well there are certainly KMS specific bugs:

              https://bugs.freedesktop.org/show_bug.cgi?id=24124
              https://bugs.freedesktop.org/show_bug.cgi?id=24263

              Though, admittedly, only the former one impacts r6xx KMS for me. And, yes, it would be nice if those bugs were fixed :-)

              There's also the various BSDs, which support direct rendering but do not yet support KMS and may not for a while.

              Adam

              Comment


              • #37
                Here's the thing -- without KMS (or at least without GEM/TTM) the 3D stack is going to be mired at GL 1.4 forever. That was OK a couple of years ago but my impression is that something more is needed today (at least GL 1.5 + GLSL) in order to be broadly useful, and even getting to GL 1.5 *does* need a memory manager.

                It's possible in principle to implement GEM/TTM without KMS, of course, but the KMS part should be much easier to port to another OS than the GEM/TTM part so it seems that fixing KMS/GEM/TTM bugs and getting GEM/TTM running on other OSes is a better use of time than backporting to UMS.

                That would obviously need to be revisited if progress on stabilizing KMS/GEM/TTM stalled for some reason.

                Comment


                • #38
                  Does anyone know how far KMS is from being considered done?

                  Comment


                  • #39
                    Originally posted by bridgman View Post
                    Here's the thing -- without KMS (or at least without GEM/TTM) the 3D stack is going to be mired at GL 1.4 forever. That was OK a couple of years ago but my impression is that something more is needed today (at least GL 1.5 + GLSL) in order to be broadly useful, and even getting to GL 1.5 *does* need a memory manager.
                    Are you sure about that? On FreeBSD, which does not have GEM/TTM/KMS I'm getting "OpenGL version string: 1.5 Mesa 7.8-devel" :-)

                    Besides, we're not talking about GLSL here, anyway. We're talking about sync-to-vblank, which apparently now has a dependency on a memory manager.

                    Comment


                    • #40
                      Yeah, I see that on my UMS system as well. It's on my list of "things to check with Alex" but my first impression is the driver reports the same GL level on UMS and KMS even though more features are available with KMS (and those features are required for GL 1.5).

                      I suspect if we look closely at extensions vs GL level on UMS we'll find some extensions missing.

                      Comment


                      • #41
                        The last thing missing for 1.5 was occlusion queries which should work in both KMS and UMS. 1.5 works on UMS, but it won't support the extensions that require a memory manager (framebuffer objects, pbuffers, etc.). These extensions aren't required for 1.5 however.

                        As for KMS, we plan to bring it out of staging in 2.6.33.

                        Comment


                        • #42
                          Originally posted by agd5f View Post
                          As for KMS, we plan to bring it out of staging in 2.6.33.
                          So a 3 months time. That's pretty good.

                          How is the feeling in the kernel developer circle about a kernel panic screen that KMS could allow?

                          Is it a touchy subject, that end in flame wars, or is there a universal agreement across the board how it should be?

                          Comment


                          • #43
                            Being able to see kernel oopses was one of the reasons behind doing kms.

                            Comment


                            • #44
                              Now that there are several kms drivers out there, is it hard so implement a "bluescreen of death" in a linux version?
                              And how far is actually the audio over HDMI in the IP-review?

                              thanks

                              Comment


                              • #45
                                Originally posted by agd5f View Post
                                Being able to see kernel oopses was one of the reasons behind doing kms.
                                I see. Have it been given a name or does there exist mock ups of how it would look like?

                                Comment

                                Working...
                                X