Page 6 of 6 FirstFirst ... 456
Results 51 to 57 of 57

Thread: A Fresh Look At The AMD Radeon Gallium3D Performance

  1. #51
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    BTW, 75% of Catalyst performance FTW! With some optimisations still on the way!

    We shouldn't open the champagne just yet, though. These are rather simple 3d applications, and I'm guessing that more recent engines are going to suffer because of the GLSL compiler.

    Once the work on GLSL 3.3 is done, we'll have OpenGL 3.3 conformance too (there are only a few extensions missing, GLSL is the biggest part). Any news on how this is going?

    Still, I'm very impressed by the improvements.

  2. #52
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Quote Originally Posted by pingufunkybeat View Post
    BTW, 75% of Catalyst performance FTW! With some optimisations still on the way!

    We shouldn't open the champagne just yet, though. These are rather simple 3d applications, and I'm guessing that more recent engines are going to suffer because of the GLSL compiler.

    Once the work on GLSL 3.3 is done, we'll have OpenGL 3.3 conformance too (there are only a few extensions missing, GLSL is the biggest part). Any news on how this is going?

    Still, I'm very impressed by the improvements.
    Ho hum, the work going on is to support GLSL 1.30 isn't it? And to get up to OpenGL 3.3 you would need to implement GLSL 1.40, 1.50 and then 3.30.

    But maybe the biggest hurdle is the step from 1.20 to 1.30?

  3. #53
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Yep, 1.30 is on the menu first (the others haven't been started). But higher GLSL functionality must be planned for some time after that is finished. I don't know how extensive the required GLSL changes are, but there must be a reason why the progress seems to be so slow.

  4. #54
    Join Date
    Sep 2010
    Posts
    146

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Yep, 1.30 is on the menu first (the others haven't been started). But higher GLSL functionality must be planned for some time after that is finished. I don't know how extensive the required GLSL changes are, but there must be a reason why the progress seems to be so slow.
    I know about the GLSL 1.30 progress in Mesa, so I'll give a summary of what's still needed.

    In the Mesa state tracker (st/mesa), the main key is my GLSL->TGSI translator that adds native integer support for drivers that support it, which is required for GLSL 1.30. I'm putting the finishing touches on that as we speak (I'm taking a short break from it to type this post), and I'm hoping to get it merged to Mesa master before the 7.11 merge window closes on June 24.

    Once that's merged, the only requirement on the driver side will be to add integer support to each Gallium driver for hardware that supports it.

    The biggest chunk of undone work is in core Mesa, though. GLSL 1.30 adds switch statements and clip distances, neither of which have been started on. As I understand it, there is also some work that needs to be done in Mesa outside of the GLSL compiler as part of the shader extensions required by OpenGL 3.0.

  5. #55
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Thanks for the update. So the majority of remaining GLSL work is in adding additional language constructs to the compiler?

    Do you know how much additional work is needed for 1.40, 1.50 and beyond? Are they small changes, or huge amounts of new functionality?

  6. #56
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Thanks for taking the time to explain things, and for doing the work in the first place, we sure do appreciate it!

  7. #57
    Join Date
    Sep 2010
    Posts
    146

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Thanks for the update. So the majority of remaining GLSL work is in adding additional language constructs to the compiler?
    Switch statements are a language construct, but gl_ClipDistance is a built-in variable that apparently needs some work in either the compiler or core Mesa to get working properly. (I'm not sure about what's needed for it, since I know less about rendering than I do about shaders.) I think we might also need gl_InstanceID and anything else required by the GL_EXT_gpu_shader4 extension.

    Quote Originally Posted by pingufunkybeat View Post
    Do you know how much additional work is needed for 1.40, 1.50 and beyond? Are they small changes, or huge amounts of new functionality?
    I don't know for sure, but probably the latter.

    Quote Originally Posted by whizse
    Thanks for taking the time to explain things, and for doing the work in the first place, we sure do appreciate it!
    Thanks for appreciating my efforts!

Posting Permissions

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