Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Now Supports GL4 Indirect Drawing Too

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

  • RadeonSI Gallium3D Now Supports GL4 Indirect Drawing Too

    Phoronix: RadeonSI Gallium3D Now Supports GL4 Indirect Drawing Too

    Just a very short time after Nouveau added support for OpenGL 4 indirect drawing, AMD developers have now added support for the related OpenGL 4.x extensions to the RadeonSI Gallium3D driver...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    If you had actually looked at the date of the patches you'd have realized they were written 3 months ago and only committed now..

    Comment


    • #3
      Also added hours ago was a Gallium3D workaround for Unigine Heaven 4.0 and Unigine Valley 1.0 to workaround poor Unigine code
      How do these things work? I guess the developers are aware of the issue, and want to fix it. Most developers want to follow the spec I guess, even though the graphics driver companies are interpreting that spec somewhat different (which REALLY should go back into the specification to clear it up and make it streamlined for everybody).
      Will Unigine make a change in their code, and Mesa will remove the work-around after a specific time? Or will it always be there, for "backwards compability"?

      Comment


      • #4
        Originally posted by Azpegath View Post
        How do these things work? I guess the developers are aware of the issue, and want to fix it. Most developers want to follow the spec I guess, even though the graphics driver companies are interpreting that spec somewhat different (which REALLY should go back into the specification to clear it up and make it streamlined for everybody).
        Will Unigine make a change in their code, and Mesa will remove the work-around after a specific time? Or will it always be there, for "backwards compability"?
        To be honest, while there used to be the excuse that "every commercial driver has small differences and it's hard to code by just a spec", this is not the case anymore. Any developer that runs his shader sources through the official reference compiler by Khronos and comes up with errors should consider their shaders broken, no matter how lenient eg. Nvidias drivers are.

        Comment


        • #5
          Originally posted by Ancurio View Post
          To be honest, while there used to be the excuse that "every commercial driver has small differences and it's hard to code by just a spec", this is not the case anymore. Any developer that runs his shader sources through the official reference compiler by Khronos and comes up with errors should consider their shaders broken, no matter how lenient eg. Nvidias drivers are.
          Cool, I didn't know that existed! Thank you for the tip!

          Comment


          • #6
            Originally posted by Azpegath View Post
            How do these things work? I guess the developers are aware of the issue, and want to fix it. Most developers want to follow the spec I guess, even though the graphics driver companies are interpreting that spec somewhat different (which REALLY should go back into the specification to clear it up and make it streamlined for everybody).
            Will Unigine make a change in their code, and Mesa will remove the work-around after a specific time? Or will it always be there, for "backwards compability"?
            The workaround is enabled based on the name of the executable file being run. You must install Mesa's drirc for the workaround to be enabled. The bug was reported to Unigine some time ago, but Unigine don't seem to care. I guess the situation would be better if we had good official OpenGL conformance tests, but the main problem is that driver developers probably sometimes don't read the spec thoroughly and app developers probably don't read it at all and just go with whatever works with a particular driver.

            I don't plan to remove the workaround, because it's fairly non-invasive and doesn't disable any features (like other workarounds do).

            Comment


            • #7
              Originally posted by marek View Post
              The workaround is enabled based on the name of the executable file being run. You must install Mesa's drirc for the workaround to be enabled. The bug was reported to Unigine some time ago, but Unigine don't seem to care. I guess the situation would be better if we had good official OpenGL conformance tests, but the main problem is that driver developers probably sometimes don't read the spec thoroughly and app developers probably don't read it at all and just go with whatever works with a particular driver.

              I don't plan to remove the workaround, because it's fairly non-invasive and doesn't disable any features (like other workarounds do).


              I believe that AMD must pay one or two independent developers with no access to MS D3D documents, in order to merge the D3D9 state_tracker to Mesa and then continue its development (its mostly based on free OpenGL state_tracker work). That will give AMD dominating position on Linux, because Intel hates Gallium and Nvidia doesn't support Mesa at all.

              Comment


              • #8
                Originally posted by artivision View Post
                I believe that AMD must pay one or two independent developers with no access to MS D3D documents, in order to merge the D3D9 state_tracker to Mesa and then continue its development (its mostly based on free OpenGL state_tracker work). That will give AMD dominating position on Linux, because Intel hates Gallium and Nvidia doesn't support Mesa at all.
                Who ever will implement the DX9 state tracker would gain a huge edge over binary drivers. The performance boost in Wine would be massive. And Wine performance on Linux is still a problem.

                Comment


                • #9
                  Originally posted by siavashserver
                  I think a D3D9 state tracker is nothing more than waste of resources. New graphics engines are mostly based on D3D10/OGL3+, even gaming consoles are equipped with DX11 level (AMD?) hardware these days.


                  A game that is written with DX11 can use all three profiles 11.5 or 10.4 or 9.3, a DX10 game can use 10.4 or 9.3 or 9.2, somewhere at compilation time. So a DX11 or a DX10 game can target a D3D9.3 state_tracker upon a DX11.5 or DX10.4 or DX9.3 compatible GPU. I hope you now that! Then i was asking for the continuation of development of the state_tracker, because one person with two years work on state_tracker can cover what five people can do in five years with shader and calls translation, an order of magnitude difference. Then i was saying that the state_tracker must be compatible with Catalyst to. You can use Mesa state_trackers and extensions with proprietary drivers even on Windowz, when you install Mesa. Just write the analogous Gallium patch and maybe a Catalyst patch.

                  Comment


                  • #10
                    Originally posted by artivision View Post
                    A game that is written with DX11 can use all three profiles 11.5 or 10.4 or 9.3, a DX10 game can use 10.4 or 9.3 or 9.2, somewhere at compilation time. So a DX11 or a DX10 game can target a D3D9.3 state_tracker upon a DX11.5 or DX10.4 or DX9.3 compatible GPU. I hope you now that! Then i was asking for the continuation of development of the state_tracker, because one person with two years work on state_tracker can cover what five people can do in five years with shader and calls translation, an order of magnitude difference. Then i was saying that the state_tracker must be compatible with Catalyst to. You can use Mesa state_trackers and extensions with proprietary drivers even on Windowz, when you install Mesa. Just write the analogous Gallium patch and maybe a Catalyst patch.
                    unless game requires feature not present in 9. something like tessellation.

                    IMHO, state tracker would be much more accepted if developers made it separated from mesa as sort of separate package and not requiring you to recompile something that works and you don't really want to touch.

                    i know i don't touch it for exact that reason, especially when knowing d3d state tracker will never will come in mesa. mesa and wine developers were clear about that. if provided as extra package... that would change the story

                    Comment

                    Working...
                    X