Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: RadeonSI Gallium3D Now Supports GL4 Indirect Drawing Too

  1. #1
    Join Date
    Jan 2007
    Posts
    15,133

    Default 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. #2
    Join Date
    Aug 2011
    Posts
    542

    Default

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

  3. #3
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    413

    Default

    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"?

  4. #4
    Join Date
    Aug 2011
    Posts
    542

    Default

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

  5. #5
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    413

    Default

    Quote 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!

  6. #6
    Join Date
    Jan 2009
    Posts
    625

    Default

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

  7. #7
    Join Date
    Apr 2011
    Posts
    357

    Default

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

  8. #8
    Join Date
    Nov 2010
    Posts
    423

    Default

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

  9. #9
    Join Date
    Oct 2013
    Posts
    195

    Default

    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.

  10. #10
    Join Date
    Apr 2011
    Posts
    357

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •