Announcement

Collapse
No announcement yet.

Linux 2.6.32 To Get R600 KMS Along With 3D

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

  • #31
    Originally posted by Louise View Post
    6 BEST? If that also applies to OpenGL 3.0 compliance, that's something I can live with

    Adding OpenGL 3.0 support to each of the GPU's sounds like an enormous task?
    OpenGL 3.0 for radeon will be built on top of Gallium3D so it'll be those r300g and r600g driver effort ratios instead + the effort that it takes to actually implement OpenGL 3.0 over Gallium3D.

    Comment


    • #32
      Originally posted by Ex-Cyber View Post
      So is it pretty reasonable to expect "classic Mesa" R600 3D support to land in the first round of 2010 distro releases?
      Sounds reasonable especially if distros won't wait for a release if it takes too long but just go with a git snapshot. (as in, I'd assume it'd be even more useful then since it can even now run games)

      Comment


      • #33
        Will the new radeon KMS eventually use UXA? Or is that only for GEM and not TTM?

        Comment


        • #34
          Originally posted by pvtcupcakes View Post
          Will the new radeon KMS eventually use UXA? Or is that only for GEM and not TTM?
          It won't, pretty much everyone is in agreement that UXA is only valuable for integrated graphics that share system memory. AMD has a few of those, but it's not worth supporting an entire architecture just for 1 or 2 models.

          What I'm less clear about is the Gallium Xorg state tracker. It's supposed to implement EXA + Xv, and use KMS for modesetting to let you remove the radeon/radeonhd driver entirely. But I don't know if it's implementing EXA like the existing drivers do, or if it's relying on the memory managers since they're required for Gallium, or what. So it might be some sort of hybrid approach. Can any developers comment on whether it's even going to be used? I see on the feature matrix that it's marked in progress, so I assume that it is, but I don't know if it is considered sufficient to completely replace radeon or if some people consider it too generic or incomplete.

          Comment


          • #35
            Originally posted by smitty3268 View Post
            It won't, pretty much everyone is in agreement that UXA is only valuable for integrated graphics that share system memory. AMD has a few of those, but it's not worth supporting an entire architecture just for 1 or 2 models.
            It's not clear that it would be of much use on our IGPs either. There are also improvements for EXA that are coming down the pipe that would need to be ported to UXA to be able to use them there.

            Originally posted by smitty3268 View Post
            What I'm less clear about is the Gallium Xorg state tracker. It's supposed to implement EXA + Xv, and use KMS for modesetting to let you remove the radeon/radeonhd driver entirely. But I don't know if it's implementing EXA like the existing drivers do, or if it's relying on the memory managers since they're required for Gallium, or what. So it might be some sort of hybrid approach. Can any developers comment on whether it's even going to be used? I see on the feature matrix that it's marked in progress, so I assume that it is, but I don't know if it is considered sufficient to completely replace radeon or if some people consider it too generic or incomplete.
            The Xorg state tracker is just like the GL or video state trackers. Once they are implemented they will work on any gallium driver. Once there is a gallium driver any state trackers should just work for the most part. That's what's neat about gallium.

            Comment


            • #36
              Awesome news, can't wait to see decent open source 3D.

              Comment


              • #37
                Originally posted by nanonyme View Post
                OpenGL 3.0 for radeon will be built on top of Gallium3D so it'll be those r300g and r600g driver effort ratios instead + the effort that it takes to actually implement OpenGL 3.0 over Gallium3D.
                I can understand that. it must be a lot more fun to work on Gallium rather than classic Mesa.

                Comment


                • #38
                  Originally posted by bridgman View Post
                  For the Mesa features marked "Mostly", 6

                  For GLSL, 21

                  Gallium 3xx-5xx, 18

                  Gallium 6xx-7xx, 33

                  Not sure about units yet. Probably different units for each line item

                  Seriously, most of the remaining work is bug fixing, eg things like text corruption when typing with Compiz active. Richard is probably also going to add support for the draw_prims driver hook, which will bring the 6xx/7xx code closer to 3xx/5xx and should deal with a few of the remaining app problems.

                  Past that, I think the focus will shift to GLSL and Gallium3D, plus maybe some power management and new GPU support.
                  What about TVout and Power Management support? Any chance of a rough estimate of when we can expect to see the feature matrix show "Done" all the way across those rows (for the radeon driver anyway, not radeonhd), or an estimate of how far along those features currently are? The article mentions KMS tvout support, will that mean feature parity with fglrx for svideo output options (last I heard you could only do NTSC at 800x600 - I want 640x480)?

                  I just noticed there seems to be a few more "Done" boxes in the Suspend Support and Console Restore lines too(great stuff!)!. An estimate of when the R700 column for those rows will no longer read "Unknown" would be much appreciated also (I'm really itching to buy a 4770 or maybe even a 4850).

                  It's really nice to see all this work finally starting to near relative completion. Great stuff.

                  Comment


                  • #39
                    Hoo-Ray! Arch Linux will get r600 OpenGL by Christmas!

                    Comment


                    • #40
                      Originally posted by oblivious_maximus View Post
                      What about TVout and Power Management support? Any chance of a rough estimate of when we can expect to see the feature matrix show "Done" all the way across those rows (for the radeon driver anyway, not radeonhd), or an estimate of how far along those features currently are? The article mentions KMS tvout support, will that mean feature parity with fglrx for svideo output options (last I heard you could only do NTSC at 800x600 - I want 640x480)?
                      TV-out on avivo chips (r5xx-r7xx) should can be considered pretty close to done at this point (add Option "ATOMTvOut" "TRUE" to the device section of your xorg config to enable). Scaling of just about any mode works. Only tv-out on the pre-avivo chips (r1xx-r4xx) is limited to 800x600.

                      Better power management is next on our list once r6xx/r7xx 3D support stabilizes a bit more.

                      Comment

                      Working...
                      X