Announcement

Collapse
No announcement yet.

The R300 GLSL Compiler Improvements Are Coming

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

  • phoronix
    started a topic The R300 GLSL Compiler Improvements Are Coming

    The R300 GLSL Compiler Improvements Are Coming

    Phoronix: The R300 GLSL Compiler Improvements Are Coming

    As we talked about back in April, there are five summer X/Mesa projects as part of Google's Summer of Code. One of these projects is to improve the GLSL (GL Shading Language) compiler for the ATI R300 class graphics processors and while the summer has just begun, there is already some work emerging...

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

  • glxextxexlg
    replied
    Originally posted by curaga View Post
    With ETRacer already often doing 300+ fps, why would it need more performance?

    There is still driver support required, even if card Y could do VBOs.
    I'm thinking in general its better to design these types of programs compatible with as much generation of hardware as possible. So the celestia people should implement an optional OGL 1.5+ VBO based vertex path in their code without killing older hardware compatibility that use OGL 1.1-1.4 vertex arrays. So if the extension is supported use it, if its not you allways have your old codepath.

    Leave a comment:


  • curaga
    replied
    With ETRacer already often doing 300+ fps, why would it need more performance?

    There is still driver support required, even if card Y could do VBOs.

    Leave a comment:


  • Agdr
    replied
    Originally posted by curaga View Post
    Built for older spec == crappy??

    Why should they raise the GL requirement to 1.5, if they currently have it lower and still work fine?
    Well, given that it is 2010, that VBOs can be supported on all hardware (and actually are), and that it is impossible to obtain optimal performance otherwise (unless using other less popular and much less standard extensions), it would seem to make sense.

    [Actually drivers could attempt to use the VM to write-protect the user data after detecting it does not change, but I don't think even the proprietary drivers dare to attempt this kind of stuff]

    Leave a comment:


  • curaga
    replied
    Anyway, all these crappy applications (tuxracer is another example) should be fixed to properly use VBOs.
    Built for older spec == crappy??

    Why should they raise the GL requirement to 1.5, if they currently have it lower and still work fine?

    Leave a comment:


  • chrisr
    replied
    I believe you.

    Originally posted by marek View Post
    I profiled celestia with sysprof and it really spends most of the time in memcpy. I think I'll try callgrind next time to be sure.
    I'm sure that r300g does indeed spend most of its time in memcpy. However, I'm equally sure that r300c cannot be doing the same thing.

    Leave a comment:


  • marek
    replied
    I profiled celestia with sysprof and it really spends most of the time in memcpy. I think I'll try callgrind next time to be sure.

    Leave a comment:


  • chrisr
    replied
    That's just it - only r300g struggles.

    Originally posted by Agdr View Post
    If all vertices are actually used, all drivers should have a similar slowdown (unless it's somehow copying to uncached memory instead of cached/WC).
    Using r300c from the same git version as my r300g, I can get just under 20 fps when I'm a mere 192 km from the Earth's surface. And this is with the "OpenGL vertex program" rendering path. So while celestia may indeed be doing something non-optimal, r300c handles it so much better than r300g.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by marek View Post
    celestia submits more and more vertices the least efficient way as you zoom in, that's all.
    Well, if it at least uses vertex arrays, it's not quite the most inefficient way but very close.

    Leave a comment:


  • Agdr
    replied
    Originally posted by chrisr View Post
    Why do fglrx, the NVIDIA binary blob and r300c all cope so much better?
    Perhaps Celestia is using indexed rendering referencing only a small subset of large vertex arrays, and r300g is uploading the whole vertex buffers instead of doing index lookup on the CPU?

    If all vertices are actually used, all drivers should have a similar slowdown (unless it's somehow copying to uncached memory instead of cached/WC).

    Anyway, all these crappy applications (tuxracer is another example) should be fixed to properly use VBOs.

    In the case of Celestia, I'm not even sure why it uses geometry, since planets are best rendered with a single quad (and projection->object mapping in the pixel shader, with KILs for pixels outside the circle).

    Leave a comment:

Working...
X