Announcement

Collapse
No announcement yet.

A Fresh Look At The AMD Radeon Gallium3D Performance

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

  • phoronix
    started a topic A Fresh Look At The AMD Radeon Gallium3D Performance

    A Fresh Look At The AMD Radeon Gallium3D Performance

    Phoronix: A Fresh Look At The AMD Radeon Gallium3D Performance

    As noted earlier in the week, the open-source AMD Radeon "R600g" driver that supports 3D acceleration on Radeon HD 2000 series graphics cards through the latest Radeon HD 6000 and Fusion graphics processors, is becoming quite fit. The driver is nearing a point of stability, is mature enough for most desktop users, and it is beginning to receive some performance optimizations and other improvements. Thanks to this recent work, plus the ongoing development of the Linux 3.0 kernel, here is a fresh set of AMD Gallium3D Linux driver benchmarks.

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

  • Plombo
    replied
    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.

    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.

    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!

    Leave a comment:


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

    Leave a comment:


  • pingufunkybeat
    replied
    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?

    Leave a comment:


  • Plombo
    replied
    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.

    Leave a comment:


  • pingufunkybeat
    replied
    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.

    Leave a comment:


  • whizse
    replied
    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?

    Leave a comment:


  • pingufunkybeat
    replied
    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.

    Leave a comment:


  • Welsh Dwarf
    replied
    @tacco:

    I already have, it was AMDs work on open source drivers that convinced me to get a radeon on my new laptop (well, that and Optimus)

    Leave a comment:


  • tacco
    replied
    Good job AMD.....if you keep up the good job i swear i will switch from Nvdia to AMD very soon. I appreciate very much your effort!

    Leave a comment:

Working...
X