Announcement

Collapse
No announcement yet.

ET:QW VBO settings with fglrx

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

  • ET:QW VBO settings with fglrx

    As I've posted in a couple of the "Catalyst 8.X Driver Released" threads, I bought a new workstation a couple of months ago, and have been having problems with Enemy Territory: Quake Wars. For the record, the system is:

    AMD Phenom 9750
    Gigabyte GA-MA790X-DS4 Motherboard
    1x 2GB 800MHz RAM
    Gigabyte Radeon HD4850

    My usual OS is Ubuntu 8.04 x86_64, which has serious problems running anything hardware-accelerated that's compiled for 32-bit x86 (but runs compiz and nexuiz 64-bit binaries fine). It's running a realtime kernel, but that seems to work as well as the generic kernel.

    To troubleshoot, I installed a completely vanilla Ubuntu 8.04 i386-generic system on another partition, and it's now using Catalyst 8.8. Quake 4 works, Nexuiz works, ETQW had problems, but I've now got it to work.

    With a fresh install, using any resolution and any of the menu-settable graphics levels, the graphics "fail" whenever the screen seems to get busy with detail, but the game continues on fine. On Catalyst 8.7, the screen froze on the current one or two frames, on 8.8 it spits huge oddly-textured triangles everywhere.

    Looking through the bugzilla, it seems to be a variant of http://ati.cchtml.com/show_bug.cgi?id=485 , caused by the handling of Vertex Buffer Objects.

    The solution that works on my system, then, is to create a "~/.etqwcl/base/autoexec.cfg" file, and put the line
    Code:
    seta r_useVertexBuffers "0"
    in it.

    This made the problem go away, but I haven't had time to do much testing with it yet. I had the game windowed at a small resolution with low-quality graphics (for testing), but once it worked I was sick of testing and just played the game for a while

    It may have just been psychological, but it seemed to me that the frame rate dropped a little in this low-quality mode, which wouldn't bode well for full-screen high-quality settings.

    There's some other settings (the full list is here), the ones I'm interested in are:
    r_useVertexBuffers ... use ARB_vertex_buffer_object for vertexes
    r_useVertexBufferStream ... Use stream instead of dynamic vbo's ( 0 = static 1 = dynamic 2 = stream
    r_vertexBufferMegs ... [no description but sounds obvious]

    - r_useVertexBuffers=0 (the big "off" switch) works, but I suspect carries a large performance hit
    - I don't know what the difference in behaviour would be between stream/dynamic VBOs, and what performance implications they have
    - As for r_vertexBufferMegs, I guess it could potentially reveal a bug if setting a limit helps. In the end, I have a feeling this is a "feature request" type of thing where full support for the extension just isn't implemented yet, but it's odd that problems with VBOs were noticed years ago on older id Tech 4 games on older hardware, and my newer hardware works with older id Tech 4 games but has problems with ETQW.
    - There's also the fact that Michael has posted a few Radeon HD48X0 reviews/benchmarks on Phoronix with ETQW in the suite of tests, and I haven't seen any reference to graphics corruption or performance-impacting workarounds in them.

    What I'm really asking, though, is if anyone has any experience with these sort of settings in ETQW or other games/programs, and any performance issues that come with them. It'd be really interesting if anyone from AMD has information on fglrx's VBO support

  • #2
    Interesting. I played around with the settings I listed, none had any effect except r_useVertexBuffers=0 (r_useVertexBufferStream defaults to 1, r_vertexBufferMegs defaults to 32 - neither raising nor lowering helped).

    I had another look at the cvars list, and found this:
    r_useIndexBuffers ... use ARB_vertex_buffer_object for indexes

    It defaulted to 0, but changing it to 1 (and leaving r_useVertexBuffers enabled) also made the problems go away

    Still haven't done any benchmarks though...

    Comment


    • #3
      Originally posted by grantek View Post
      Interesting. I played around with the settings I listed, none had any effect except r_useVertexBuffers=0 (r_useVertexBufferStream defaults to 1, r_vertexBufferMegs defaults to 32 - neither raising nor lowering helped).

      I had another look at the cvars list, and found this:
      r_useIndexBuffers ... use ARB_vertex_buffer_object for indexes

      It defaulted to 0, but changing it to 1 (and leaving r_useVertexBuffers enabled) also made the problems go away

      Still haven't done any benchmarks though...
      ETQW does seem to be a fickle game - for me at least.
      I tried your seta r_useVertexBuffers "0"

      and it threw a warning -
      WARNING: vertex array range in virtual memory (SLOW)
      and segfaulted so I didn't get to see how slow :-)

      I recently found a reliable way to break it - run it with AIGLX by doing
      export LIBGL_ALWAYS_INDIRECT=1

      I got 12 fps on the spash screen and a segfault on trying to start a map.
      The interesting thing is the game will be unstable after that - true power cycle and start normally with direct rendering and it would lockup 5 - 30 sec after starting a map.

      I had managed to do this before on a different card and then it would lock with trashed screen/triangles - but only on some maps.

      The solution is to delete ~/.etqwcl and let it regenerate it. I keep a backup now, though it would be better to find exactly what part of it needs deleting/restoring so as not to affect anything achievement/stats related that is stored.

      Even when it's stable - which it normally is, it doesn't quite render smoothly.
      It's not bad enough to affect gameplay - but if I just join an empty server and in spectator mode fly left/right I see two effects:

      Slight glitching + if I am looking at detail, say the side of a container or poster, as soon as the screen scrolls the detail becomes jittery so it looses clarity.

      Doom 3 demo (related engine) does the same.

      My setup -

      32 bit XP2500 @ 2.1 GHz uniprocessor
      HD3850 AGP
      LFS - Xorg 7.2 (happens in win XP as well)

      Comment


      • #4
        Originally posted by legume View Post
        The solution is to delete ~/.etqwcl and let it regenerate it. I keep a backup now, though it would be better to find exactly what part of it needs deleting/restoring so as not to affect anything achievement/stats related that is stored.
        If you can reliably get it into the bad state again, try doing a diff of ~/etqwcl/base/etqwconfig.cfg and your ~/etqwcl-regenerated/base/etqwconfig.cfg - I made a typo in one of the settings in autoexec.cfg, and saw the new variable got saved in etqwconfig.cfg

        Originally posted by legume
        LFS - Xorg 7.2 (happens in win XP as well)
        Oooh, now that's interesting - have you taken a look at the etqw community forums to see if anyone else has the same issue?

        Comment


        • #5
          Woohoo!

          Did some benchmarks with the PTS demo and the settings I normally play at, and got:

          VBs and no IBs (original settings, screen corruption): ~67FPS
          no VBs and no IBs (no corruption): ~49FPS
          VBs and IBs (no corruption): ~67FPS

          Comment


          • #6
            Originally posted by grantek View Post
            If you can reliably get it into the bad state again, try doing a diff of ~/etqwcl/base/etqwconfig.cfg and your ~/etqwcl-regenerated/base/etqwconfig.cfg - I made a typo in one of the settings in autoexec.cfg, and saw the new variable got saved in etqwconfig.cfg
            I redid the test copying .etqwcl before and after. Did a diff -r etqwcl-working/ etqwcl-broken/ and apart from logging/pids the only difference was -

            < seta r_useIndexBuffers "1"
            ---
            > seta r_useIndexBuffers "0"

            The symptoms were also as you describe with 8.8. Flying around an empty refinery server I thought it was working OK at first, but then in certain places looking/flying forward towards the strogg base would give a acreen full of triangles. Reversing/looking away would fix it. I eventually crashed (sysrq-able) by continuing flying into the corruption.

            Oooh, now that's interesting - have you taken a look at the etqw community forums to see if anyone else has the same issue?
            I have looked before but didn't see anything. The problem isn't that noticeable if moving forwards/backwards and I am too busy in a real game to notice that much, but no other games I have do it.

            Comment

            Working...
            X