Announcement

Collapse
No announcement yet.

r6xx 3D games

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

  • after i rebuilt drm and mesa again, it finaly works fine again, openarena has no glitches, indirect rendering only for quake3 still, but it has no glitches too, i have drawprim disabled with patch posted here earlier.

    Comment


    • Is anyone playing things using the free drivers on r6xx+ ?

      What i'm observing on my HD4550 is frame rates between 40 and 80 in OpenArena, with very little relation to detail/complexity level and resolution.

      I've tried many different combinations, and basically I get similar frame rates using vertex lighting and minimum detail at 800x600 and full-blown everything on at 1920x1080. There is some difference, but I can't hit 125fps, whatever I do.

      What does this mean? It's hard to imagine that the card is not powerful enough (at low res), the engine is 10 years old. I guess that the fill rate is not the issue, as the resolution doesn't matter much. Where is the bottleneck? Is there hope for improvement?

      Another thing I've noticed is that the frame rate is very unstable and fluctuates wildly, even when you're staring at a wall. On top of this, there are sticky points every 2 seconds or so (screen freezes for a split second), which gets worse the longer X has been running. Upgrading to the latest drm-next kernel has improved this significantly, but it's still there.

      This is not moaning, just a discussion, and I do appreciate the efforts that have gone into the drivers. We've had a few trolls here recently, so I wanted to make that clear.

      Comment


      • If the frame rate doesn't change much with resolution that means you're either CPU bound or limited by the driver's ability to overlap GPU and CPU processing.

        Are you running with KMS ? If so the new memory manager code is probably introducing some frame rate variations, but that will improve over time.

        Comment


        • I wonder about:
          Code:
          *** NOTE: Don't use glxgears as a benchmark.
              OpenGL implementations are not optimized for frame rates >> 60fps,
              thus these numbers are meaningless when compared between vendors.
          I get this with glxgears. But maybe 60fps is for all OpenGL apps?

          Comment


          • Yeah, the drivers are written for real world apps that do a lot of drawing in each frame, ie the drawing code gets more attention than the "once per frame" code.

            The glxgears program draws so little each frame that you end up measuring the performance of the "once per frame" code rather than the drawing code -- so the correlation between glxgears performance and real world application performance is weak at best.

            That's why the devs make rude comments about glxgears being used as a benchmark for anything other than buffer-flipping. Any frame rate faster than your display refresh rate is largely wasted anyways.
            Last edited by bridgman; 11-20-2009, 11:28 AM.

            Comment


            • Originally posted by bridgman View Post
              Yeah, the drivers are written for real world apps that do a lot of drawing in each frame, ie the drawing code gets more attention than the "once per frame" code.

              The glxgears program draws so little each frame that you end up measuring the performance of the "once per frame" code rather than the drawing code -- so the correlation between glxgears performance and real world application performance is weak at best.

              That's why the devs make rude comments about glxgears being used as a benchmark for anything other than buffer-flipping. Any frame rate faster than your display refresh rate is largely wasted anyways.
              Ups, that's not really want I meant.

              I know exactly glxgears is winner of the worst benchmark

              I meant maybe whole Mesa is not written to achieve more than 60fps? Don't know much about 3D however, that's why I ask.

              Comment


              • That was the question I answered

                Put differently, the mesa code has no trouble running at faster than 60 hz (unless you have sync-to-vblank enabled and have a 60 hz display, of course) but nobody really cares if it runs a trivial app at 770 fps or 6000 fps since displays max out around 120 fps anyways.

                Putting effort into making the per-frame code go faster would only make a real difference on trivial apps with very high frame rates, which don't correlate well with real world performance anyways.

                Comment


                • Thanks for re-explaining It seems I try to understand too much things like for one day

                  Comment


                  • Originally posted by bridgman View Post
                    If the frame rate doesn't change much with resolution that means you're either CPU bound or limited by the driver's ability to overlap GPU and CPU processing.
                    Thanks for the reply. It is definitely not CPU bound in this case, on a Phenom II quad. I could probably render OpenArena in software

                    Are you running with KMS ? If so the new memory manager code is probably introducing some frame rate variations, but that will improve over time.
                    Yes, I'm running with KMS, which is when the freezes started appearing. Updates to drm-next have improved the situation, so I guess that KMS does play a role in all of this.

                    but nobody really cares if it runs a trivial app at 770 fps or 6000 fps since displays max out around 120 fps anyways.
                    Yes and no.

                    Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.

                    It is also very important to have a stable frame rate. Which means that you must be able to render more than 60 per second in most situations, so you can still keep this rate during very complex scenes.
                    Last edited by pingufunkybeat; 11-20-2009, 12:38 PM.

                    Comment


                    • Originally posted by pingufunkybeat View Post
                      Yes, I'm running with KMS, which is when the freezes started appearing. Updates to drm-next have improved the situation, so I guess that KMS does play a role in all of this.
                      The memory manager is probably the largest factor. It's not currently very well optimized. Placement of buffers and when to migrate (gart vs. vram vs. unmappable vram) can make a huge difference for performance. Right now we are just getting the infrastructure in place and making it stable. After that, we need to profile usage patterns and tune the memory manager accordingly.
                      Last edited by agd5f; 11-20-2009, 04:04 PM.

                      Comment


                      • Originally posted by pingufunkybeat View Post
                        Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.

                        It is also very important to have a stable frame rate. Which means that you must be able to render more than 60 per second in most situations, so you can still keep this rate during very complex scenes.
                        I picked the numbers carefully. Getting decent frame rates for games and other apps is a concern, but getting thousands of fps is not.

                        Comment


                        • Can I ask where newest bleeding-edge DRM r600 module I can compile and test is? I'm using ubuntu lucid kernel (based on 2.6.32-rc7 AFAIK) and mesa master but I have some problems with 3d. Well... 3d works great, but framerates aren't high. Stable 30-40 fps wouldn't be a problem, but my fps drops from time to time perfectly killing whole gaming experience.
                          If there is any code that would improve this, I can test it.
                          Thanks

                          Comment


                          • Still can't get etracer to work, it complains about missing visuals.

                            Anyone had a luck with it ?

                            Comment


                            • Originally posted by pingufunkybeat View Post
                              Thanks for the reply. It is definitely not CPU bound in this case, on a Phenom II quad. I could probably render OpenArena in software
                              Just for laughs, what do you get with LIBGL_ALWAYS_SOFTWARE=1 :-)

                              Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.
                              Just in case you didn't already tweak it com_maxfps defaults to 85 in OA (apart from timedemos)

                              I haven't seen any glitching on OA with my setup. With the current version the bloom kills fps, but I can use every thing else on/up @ 1280x1024 without issue.

                              I get 57fps with anholt demo on rv670 with Athlon XP 2500 @ 2.1GHz.

                              Maybe the glitching is due to other things running - I saw a bit on glxgears when I last tried a F12 beta KDE live CD.

                              Comment


                              • Is there an ETA on fixing the openarena darkness bug?

                                It's been extremely dark for a few weeks now.

                                Does anyone know a workaround?

                                Comment

                                Working...
                                X