Announcement

Collapse
No announcement yet.

AMD RadeonSI Gallium3D Is Now Incredibly Close To OpenGL 4.3!

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

  • #11
    On the other hand, compute shaders don't work really well with e.g. these examples anyway. https://github.com/McNopper/OpenGL/
    For example here is an apitrace for example30 that shows a raytracing scene on intel with MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430, but on radeonsi it just shows gray window content (with no error message this time): http://haagch.frickel.club/files/McN...xample30.trace

    On the other hand, example40 works fine on radeonsi, but is pretty broken (but at least displays something) on intel. I've reported this here, because it seemed like a nice small test case: https://bugs.freedesktop.org/show_bug.cgi?id=94858

    Comment


    • #12
      Too much green, I cannot see anymore... x_X

      Congratz guys !!

      Comment


      • #13
        Originally posted by kcybulski View Post
        GL_ARB_clear_texture at last one month, according to https://www.phoronix.com/forums/foru...839#post863839
        sorry, i was not clear on this.
        i meant there is at least one month between now and feature freeze, not that this ext needs one month of work

        Comment


        • #14
          Originally posted by Drago View Post
          It would be not surprising if Radeon ( and possibly others ) get full GL 4.5 this calendar year
          It would be not surprising if Radeon get full GL 4.5 this summer

          Comment


          • #15
            Originally posted by ernstp View Post
            One very advanced patch is missing for 4.2: https://lists.freedesktop.org/archiv...il/112547.html :-)
            I wonder why it didn't go with this final patchset for 4.2.

            Comment


            • #16
              Originally posted by geearf View Post
              I wonder why it didn't go with this final patchset for 4.2.
              Just good practice to keep them separate. You have many patches and commits that add all the bits required to support 4.2 - it's not all that significant that one of those patches just happens to be the last one required to meet the spec. So actually updating the docs and code to claim 4.2 compliance should always be a separate commit - applied after you've actually confirmed that you've not missed anything.

              Comment


              • #17
                Originally posted by haagch View Post
                It also needs llvm with 2 non mainline patches. Or are they mainline now? I haven't kept up.
                If you're talking about the shader buffer load/store intrinsics, those just landed today:
                (svn id: https://llvm.org/svn/llvm-project/llvm/trunk@266126
                , git: 756309c45b935a28a3bdd2ddbdebcfb27b4a1a82)

                Comment


                • #18
                  Originally posted by pal666 View Post
                  It would be not surprising if Radeon get full GL 4.5 this summer
                  I'm not sure how much work is left on ES 3.1 compatibility extension for 4.5. It seems like Intel has shifted some resources away from ES support and towards Vulkan, so it may not be finished up by this summer.

                  The rest probably will be though.

                  4.3 is really the major milestone that the driver needs to be usable by modern games these days, so that will be a big deal when it finally goes in.

                  4.3 compute shaders (patches out - this should be committed any day now, i believe)
                  4.4 clear_texture (not started yet? but other drivers have it and it shouldn't be too tough i don't think)
                  4.4 query_buffer_object (in progress)
                  4.4 enhanced_layouts (patches are out - mostly reviewed but no one wants to look at the final handful)
                  4.5 cull_distance (patches out, needs some work)
                  4.5 ES3_1_compatibility (in progress)

                  I'm guessing 4.6 will probably get announced sometime this summer as well, so they'll still have plenty to work on with that as well as opening Vulkan and various perf optimizations.
                  Last edited by smitty3268; 12 April 2016, 11:59 PM.

                  Comment


                  • #19
                    Originally posted by Delgarde View Post

                    Just good practice to keep them separate. You have many patches and commits that add all the bits required to support 4.2 - it's not all that significant that one of those patches just happens to be the last one required to meet the spec. So actually updating the docs and code to claim 4.2 compliance should always be a separate commit - applied after you've actually confirmed that you've not missed anything.
                    A separate commit yes, but why a separate set of commits?

                    Anyway, it's in!

                    Comment


                    • #20
                      Originally posted by geearf View Post
                      A separate commit yes, but why a separate set of commits?

                      Anyway, it's in!
                      Because when the original patchset was being written, it wasn't clear that it would be the final 4.2 extension to go in. It was started before the robust buffer access behaviour patches, for example.

                      So there wasn't really any point in modifying the already existing patchset at this point. Just push it in, and then create a new one to finish off 4.2.

                      Comment

                      Working...
                      X