Announcement

Collapse
No announcement yet.

The R300 GLSL Compiler Improvements Are Coming

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

  • #41
    Progress with the latest r300g

    Originally posted by marek View Post
    So the problem is celestia is submitting lots of vertices using vertex arrays without use of VBOs. The driver spends most of the time in memcpy, copying vertices from a user pointer to a mapped vertex buffer. The copying takes place in u_upload_mgr. Currently I have no idea what to do about it.
    I have tested celestia again with r300g from git, and it seems to be doing slightly better at this test. The critical distance from the Earth where the FPS drops from about 28 to only 2.x has decreased to about 48,600 km. You can actually see the Earth at this range ;-). The drop in FPS if you zoom in closer than this is very sharp, so presumably celestia starts doing extra processing at this point.

    Comment


    • #42
      Heh i just bought a sparkle radeon 9800 pro off of ebay to put in my oldest running PC of the following specs.

      Tyan Thunder 2 ATX
      Dual PII@300Mhz not overclockable as the 440LX chipset probably can't handle increased PCI bus frequency.
      AGP 1.0 2x
      512Mb ram
      OPL2-SA3 audio (works on Netbsd BeOS and Windows... not Linux :-/)

      I'll probably have to add a second PSU for the radeon 9800 since I only have a 250watt PSU

      I'll post benchmarks of it around august 20th after I get back home. I figure the APG 2x is going to cause some drastic performance loss but should still be acceptable it may even provide a bit of insight into how to better optimise for interface bandwidth dunno. From the PICS of the card it does have the 3.3v notch so I should be set to run on AGP 1.0.

      So yeah improved open source support is always welcome :-) note that this is an upgrade from an ATI rage pro turbo AGP 2x which is slow as molasses even when it is accelerated by the mach64 driver.

      Comment


      • #43
        Originally posted by chrisr View Post
        I have tested celestia again with r300g from git, and it seems to be doing slightly better at this test. The critical distance from the Earth where the FPS drops from about 28 to only 2.x has decreased to about 48,600 km. You can actually see the Earth at this range ;-). The drop in FPS if you zoom in closer than this is very sharp, so presumably celestia starts doing extra processing at this point.
        celestia submits more and more vertices the least efficient way as you zoom in, that's all.

        Comment


        • #44
          But if it's all celestia's fault...

          Originally posted by marek View Post
          celestia submits more and more vertices the least efficient way as you zoom in, that's all.
          Why do fglrx, the NVIDIA binary blob and r300c all cope so much better?

          Comment


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

            Comment


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

              Comment


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

                Comment


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

                  Comment


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

                    Comment


                    • #50
                      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?

                      Comment

                      Working...
                      X