Announcement

Collapse
No announcement yet.

Radeon Driver Picks Up VBOs, OQ Support

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

  • Radeon Driver Picks Up VBOs, OQ Support

    Phoronix: Radeon Driver Picks Up VBOs, OQ Support

    There are quite a number of changes in store for Mesa 7.6, such as new state trackers for Gallium3D, other Gallium3D-specific improvements, optimized IR, and many changes to the different Mesa 3D drivers. Adding to that list, the open-source ATI R300+ driver has just picked up support for Vertex Buffer Objects and Occlusion Queries. The vbo_clean branch was merged into Mesa over the weekend, which adds hardware-based VBO support for those with newer ATI Radeon graphics cards...

    http://www.phoronix.com/vr.php?view=NzQ1OQ

  • #2
    I can't stress enough the importance of this addition. Mesa git master should now report OpenGL 1.5 for ATI cards R300-R500. OTOH, what took them so long?

    Comment


    • #3
      benchmarks

      I can't wait for you guys to benchmark these new drivers. A nice comparison with the older OSS and the latest Catalyst.

      Comment


      • #4
        This is awesome news! Occlusion support is something i've been looking forward to.

        Comment


        • #5
          Originally posted by crumja View Post
          I can't stress enough the importance of this addition. Mesa git master should now report OpenGL 1.5 for ATI cards R300-R500. OTOH, what took them so long?
          Great! The open drivers are finally moving from toy to real 3d support.

          This couldn't be implemented earlier, due to the lack of a memory manager.

          Comment


          • #6
            Meh, already the former OpenGL 1.4 support was imo pretty much more than a toy...
            Wonder how many actual features there are left to go (in addition to the bug fixes) before they can focus on Gallium3D and OpenGL 2.0.

            Comment


            • #7
              Originally posted by nanonyme View Post
              Meh, already the former OpenGL 1.4 support was imo pretty much more than a toy...
              Wonder how many actual features there are left to go (in addition to the bug fixes) before they can focus on Gallium3D and OpenGL 2.0.
              IIRC the only real big addition between GL 1.5 and 2.0 was the introduction of GLSL. So I guess, that's what's needed to bump up the version (does the OSS driver support GLSL already?).

              EDIT: OK, not just GLSL, there was also: Point Sprites (GL_ARB_point_sprite), Separate Blend Equation (GL_EXT_blend_equation_separate) and Separate Stencil (GL_ATI_separate_stencil). But the others are relatively minor in comparison to GLSL.
              Last edited by Kazade; 08-17-2009, 05:01 AM.

              Comment


              • #8
                Can't wait till this starts shipping with distros, since my kernel update I can only use the OSS drivers, and they really needed VBO. Keep the good work!

                Comment


                • #9
                  hmmmm
                  HMMMMM
                  NEAT!
                  I have nothing against the blob (it always worked on my 9600pro, now I have hd4850 and it also works) but such great improvements in open source driver are very welcome! Keep up the good work!

                  Comment


                  • #10
                    Originally posted by nanonyme View Post
                    Meh, already the former OpenGL 1.4 support was imo pretty much more than a toy...
                    Depends on your viewpoint, I guess. Personally, I consider anything less than OpenGL 2.1 + FBOs a "toy" - we are talking about 6 year old features here!

                    (Not bashing the open-source drivers, just saying I'd *really* love GLSL support so I can finally drop the damned fixed-function codepath from my applications).
                    Last edited by BlackStar; 08-17-2009, 09:35 AM.

                    Comment


                    • #11
                      Good news. Looking forward for test results from Michael.

                      Comment


                      • #12
                        also a compliment on the article to michael. afaik its the first time he provided useful links to the technical details

                        Comment


                        • #13
                          Originally posted by BlackStar View Post
                          Depends on your viewpoint, I guess. Personally, I consider anything less than OpenGL 2.1 + FBOs a "toy" - we are talking about 6 year old features here!

                          (Not bashing the open-source drivers here, just saying I'd *really* love GLSL support so I Can finally drop the damned fixed-function codepath from my applications).
                          R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.

                          Comment


                          • #14
                            Originally posted by chelobaka View Post
                            Good news. Looking forward for test results from Michael.
                            Don't expect much. Only apps that feed GPU with much vertex data will benefit from vbo_clean branch merge, and as for occlusion queries on low end GPUs people may actually see performance drop (because app may have software and hardware OQ backends, and the SW-based one can be faster for slower GPUs - that's the case with sauerbraten game).

                            Comment


                            • #15
                              Originally posted by osiris View Post
                              R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.
                              Loops are not necessary for a surprising number of algorithms: per-pixel lighting, shadow maps, parallax can all be implemented without loops. These represent a huge jump in quality over fixed function OpenGL, so they are certainly worth it (true, you *could* implement shadow maps and dot3 lighting without on fixed function hardware, but the implementation is not even funny).

                              Other than that, I refuse to touch ARB_vertex/fragment programs (adding *yet* another codepath to my applications for obsolete hardware? No thanks!) If a GPU doesn't support GLSL I force it down the fixed-function pipeline and forget about it (which includes every Intel GPU currently in existence.)

                              My point is that across-the-board GLSL support allows you to provide a unified and relatively clean rendering engine. Supporting the fixed function pipeline makes things much, *much* uglier.

                              Edit: regarding VBOs, they are much easier to handle than client-side vertex arrays for a number of applications (esp. if you are using a GC). They also allow you to use a single codepath for basic geometry uploads, which is always a good thing.

                              Speed will probably increase as the code matures.
                              Last edited by BlackStar; 08-17-2009, 09:45 AM.

                              Comment

                              Working...
                              X