Announcement

Collapse
No announcement yet.

Radeon OpenGL 2.0 support

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

  • Radeon OpenGL 2.0 support

    IIRC the latest Mesa already supports OpenGL 2.0. Is there any ETA as to when ATI radeon and radeonhd driver will support openGL 2.0? It's becoming a real PITA not being able to have shaders in 3D with this card (R500, so no fglrx, no GLSL).

    AFAIK the kernel changes are now in (at least for R500-).

  • #2
    Just for clarification, the current driver *does* support shaders and most of the games running on them are using shaders. What they don't support is GLSL - only the ARB_vp/fp shader language. The changes to support GLSL and OpenGL 2.0 will mostly be made in the mesa drivers, not radeon/radeonhd.

    Availability of kernel modesetting (actually the GEM/TTM memory manager that comes with kernel modesetting) was a pre-requisite for some of the GL 2.0 functions, and also a pre-requisite for the Gallium3D drivers which will be the most likely path to GL 2.0. Now that KMS/GEM/TTM are available in the kernel tree, work on Gallium3D is starting to ramp up.

    It's probably a bit early to make schedule estimates... maybe check back in a month.
    Last edited by bridgman; 09-22-2009, 06:26 PM.

    Comment


    • #3
      There is no GLSL yet, but I'm working on it as time permits. However, I also want to push the Gallium driver r300g which has some catching up to do, so that slows things down a little.

      I can't give you a good timeframe, unfortunately. It might happen in Mesa 7.7 or not, it's not clear at the moment.

      Comment


      • #4
        Originally posted by nhaehnle View Post
        There is no GLSL yet, but I'm working on it as time permits. However, I also want to push the Gallium driver r300g which has some catching up to do, so that slows things down a little.

        I can't give you a good timeframe, unfortunately. It might happen in Mesa 7.7 or not, it's not clear at the moment.
        Thanks for the info. I highly value your work on the OSS drivers so don't get me wrong, it's just that I'm getting a bit frustrated by not being able to use a 2 year old gfx card on linux properly (especially now since I got invited to Heroes of Newerth beta ).

        Anyways, if you need a tester for R500 (Mobility X1600) give me a PM. I got some simple as well as more complicated GLSL stuff here.

        Comment


        • #5
          For some trivial to not that complicated GLSL Mesa offers some tests but I'm sure your code would be plenty useful for testing. (especially so if it's opensource and other people can download the source and compile it too) That is, in the days when GLSL support will be in the drivers.

          Comment


          • #6
            There was some discussion a while back about whether it made sense to try enabling GLSL before the flow control instructions were fully implemented in the driver, since there seemed to be a number of apps which required GLSL but which didn't actually use any shader functions which were not already handled by the ARB_FP/VP support.

            I'm not sure where that discussion ended but it might be worth reviving. It would not affect the need to get to GL 2.x support but might make it possible to provide support more quickly for a number of GLSL-only applications.

            I guess what we really need is an instrumentation layer that dumps out a summary of all the capabilities used by the application.
            Last edited by bridgman; 09-24-2009, 10:34 AM.

            Comment


            • #7
              One GLSL-using application that does spring to mind...

              Originally posted by bridgman View Post
              ... but might make it possible to provide support more quickly for a number of GLSL-only applications.
              http://blogs.adobe.com/penguin.swf/2...s_the_gpu.html

              It uses OpenGL and we require the following features before we consider honoring the new SWF GPU features:

              * GL_ARB_multitexture
              * GL_EXT_framebuffer_object
              * GL_ARB_shader_objects
              * GL_ARB_shading_language_100
              * GL_ARB_fragment_shader

              Comment


              • #8
                Okay, that's another interesting argument in favour of GLSL without 2.0.

                Comment


                • #9
                  Lots of recent movement in mesa master concerning i915g and r300g drivers. Any idea how we can test those drivers now?

                  Comment


                  • #10
                    To test the Gallium drivers, you first need to enable building them (--enable-gallium-radeon --with-state-trackers=dri,glx). Then the build system provides a radeon_dri.so, which should be renamed or linked to as r300_dri.so from some other directory. Then you can set the LIBGL_DRIVERS_DIR environment variable to test the driver for specific applications only.

                    Comment


                    • #11
                      Originally posted by nhaehnle View Post
                      To test the Gallium drivers, you first need to enable building them (--enable-gallium-radeon --with-state-trackers=dri,glx). Then the build system provides a radeon_dri.so, which should be renamed or linked to as r300_dri.so from some other directory. Then you can set the LIBGL_DRIVERS_DIR environment variable to test the driver for specific applications only.
                      OpenGL vendor string: X.Org R300 Project
                      OpenGL renderer string: Gallium 0.3 on RV350
                      OpenGL version string: 1.5 Mesa 7.7-devel

                      Thamk you! Seems to load.

                      But I have some problems. For example after running glxgears more than 7 seconds X hangs. glxgears itself shows some mystic things. Is it normal at this time or I should check something on my system?
                      Mesa built with state-trackers=dri,glx,egl
                      Last edited by mcdebugger; 09-30-2009, 03:39 AM.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Just for clarification, the current driver *does* support shaders and most of the games running on them are using shaders. What they don't support is GLSL - only the ARB_vp/fp shader language. The changes to support GLSL and OpenGL 2.0 will mostly be made in the mesa drivers, not radeon/radeonhd.

                        Availability of kernel modesetting (actually the GEM/TTM memory manager that comes with kernel modesetting) was a pre-requisite for some of the GL 2.0 functions, and also a pre-requisite for the Gallium3D drivers which will be the most likely path to GL 2.0. Now that KMS/GEM/TTM are available in the kernel tree, work on Gallium3D is starting to ramp up.

                        It's probably a bit early to make schedule estimates... maybe check back in a month.
                        I am currently trying to write a shader based engine to get the concepts of OpenGL3 and since you decided to cripple my R500 card with open-source drivers, I try to use ARB_vp/fp where GLSL is mentioned in the tutorials.
                        But it seems like ARB_vp/ fp is not well documented - probably because its obsolete and old. Do you perhaps still know some documentation sources? (besides the extension text)

                        Comment


                        • #13
                          Originally posted by mcdebugger View Post
                          But I have some problems. For example after running glxgears more than 7 seconds X hangs. glxgears itself shows some mystic things. Is it normal at this time or I should check something on my system?
                          Mesa built with state-trackers=dri,glx,egl
                          Definitely not normal but whether it's a known issue or not, you can find out in fd.o bugzilla.

                          Comment


                          • #14
                            Originally posted by madman2k View Post
                            ... since you decided to cripple my R500 card with open-source drivers ...
                            Ooookay?

                            About the Gallium issue: Yeah, known bug on R300 cards. I haven't found the time to understand it, unfortunately.

                            Comment


                            • #15
                              Originally posted by nhaehnle View Post
                              Ooookay?
                              nothing personal. I would have just preferred to have a feature complete Open Source driver, before AMD cut off the closed source support.
                              Right now I ended up without power management and without OpenGL3, which I would have with the closed source drivers.

                              But I am happy if you give me some vertex_program documentation.

                              Comment

                              Working...
                              X