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...

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

  • #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
                  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.

                  Comment


                  • #10
                    Originally posted by siavashserver View Post
                    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


                    • #11
                      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!
                      I don't know how did you come up with 11.5 and 10.4, but that's okay for now . Yes, a DX11 based graphics engine will run on older DX10 and DX9 hardware, but that's only possible when developers write multiple fallback versions and do limit their engine to that level of hardware features.

                      So why invest in rewriting the whole thing in DX11 but limit yourself to DX9 level hardware again? How many (real) games with a DX11 (only) based graphics engine do you see in market which don't list their minimum hardware requirements as a DX11 level GPU?

                      Comment


                      • #12
                        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


                        • #13
                          Originally posted by Ancurio View Post
                          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..
                          There's nothing in the article stating (or even implying) otherwise. What is your point?

                          Comment


                          • #14
                            Originally posted by siavashserver View Post
                            I don't know how did you come up with 11.5 and 10.4, but that's okay for now . Yes, a DX11 based graphics engine will run on older DX10 and DX9 hardware, but that's only possible when developers write multiple fallback versions and do limit their engine to that level of hardware features.

                            So why invest in rewriting the whole thing in DX11 but limit yourself to DX9 level hardware again? How many (real) games with a DX11 (only) based graphics engine do you see in market which don't list their minimum hardware requirements as a DX11 level GPU?


                            I don't now any such game. Some DX11 games wants you to have DX11 installed but they don't require a DX11.5 GPU (0.5 compiler profile = shader model 5). Those games can be measured with just one hand. Also this legacy compatibility writing is part of a game engine profiles, so is not so much extra job, it is always there. Also a game with legacy support it's only limited with older hardware, you don't have graphics limitations with new hardware. For example tessellation can be ON or OFF to older hardware.
                            Last edited by artivision; 07-18-2014, 10:41 AM.

                            Comment


                            • #15
                              Originally posted by DanL View Post
                              There's nothing in the article stating (or even implying) otherwise. What is your point?
                              It's just confusing because Michael keeps bouncing between announcing new features that are posted on the ML, and new features finally committed to master.

                              Comment

                              Working...
                              X