Announcement

Collapse
No announcement yet.

radeon with DRI2 slower?

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

  • #11
    Originally posted by madman2k View Post
    Is there a way to disable vsync with DRI2? I am using the Xorg edgers PPA, so everything is just several days old...
    Is there an option in Chromium to disable vsync?

    There are also (or used to be) options for vsync in the driconf (use the driconf application to view & change). To be honest, I'm not sure if those actually work correctly, I have to admit that this is not my area of expertise.

    Comment


    • #12
      using driconf has no effect. Neither has disabeling vsync in openarena (where is an option to do so). I probably should ask on IRC or something
      Last edited by madman2k; 09-08-2009, 06:01 PM.

      Comment


      • #13
        Hi all,

        I saw chart with test report on www.free3d.org and wanted to check how well performs x1600 on Fedora 11 in glxgears. FPS rate (ca. 600 fps) was lower than in test reports for this card so I fired up Ubuntu 9.04 live CD and recived much better FPS rate (ca. 2300 fps). Here are the results of testing script mentioned on that site.

        Fedora 11
        0.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]
        model name : Mobile AMD Sempron(tm) Processor 3400+
        cpu MHz : 800.000
        X.Org version: 1.6.3.901
        dimensions: 1280x800 pixels (338x211 millimeters)
        depth of root window: 24 planes
        direct rendering: Yes
        server glx vendor string: SGI
        server glx version string: 1.2
        --
        OpenGL vendor string: DRI R300 Project
        OpenGL renderer string: Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2
        OpenGL version string: 1.4 Mesa 7.6-devel
        Linux 2.6.30.5-43.fc11.i686.PAE
        [1] 4826
        3031 frames in 5.0 seconds = 606.196 FPS
        3084 frames in 5.0 seconds = 616.757 FPS
        3070 frames in 5.0 seconds = 613.844 FPS
        3069 frames in 5.0 seconds = 613.692 FPS
        2842 frames in 5.0 seconds = 568.293 FPS

        Ubuntu 9.04:
        0.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600]
        model name : Mobile AMD Sempron(tm) Processor 3400+
        cpu MHz : 800.000
        X.Org version: 1.6.0
        dimensions: 1280x800 pixels (338x211 millimeters)
        depth of root window: 24 planes
        direct rendering: Yes
        server glx vendor string: SGI
        server glx version string: 1.2
        --
        OpenGL vendor string: DRI R300 Project
        OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 TCL
        OpenGL version string: 1.3 Mesa 7.4
        Linux 2.6.28-11-generic
        [1] 5070
        12044 frames in 5.0 seconds = 2408.769 FPS
        12119 frames in 5.0 seconds = 2423.689 FPS
        12181 frames in 5.0 seconds = 2436.176 FPS
        11745 frames in 5.0 seconds = 2348.968 FPS
        11585 frames in 5.0 seconds = 2316.902 FPS

        I've red Testing Out AMD's DRI2 Driver Stack and infered that maybe DRI2 is to blame.
        My question is: Is it possible to easy change OpenGL renderer to DRI on Fedora 11 so I could get better performance?

        Thanks in advance for all replies.

        Comment


        • #14
          I recommend against reading that page, they have no idea what they're talking about. If you seriously want to stop using KMS, you can do radeon.modeset=0 in Fedora but this will rid you of FBO's. The Fedora results are actually really better in that sense...

          Comment


          • #15
            Originally posted by nanonyme View Post
            If you seriously want to stop using KMS, you can do radeon.modeset=0 in Fedora but this will rid you of FBO's.
            What I want is the best performance on Fedora 11, and i suspect that FBO is required for that.

            Originally posted by nanonyme View Post
            The Fedora results are actually really better in that sense...
            In my reasoning glxgears shows how well card performs. Card have considerably more fps in Ubuntu so Ubuntu is better or maybe shouldn't I look at fps value during my comparison?
            Last edited by NSLW; 09-20-2009, 05:12 AM. Reason: question tag added

            Comment


            • #16
              Originally posted by madman2k View Post
              using driconf has no effect. Neither has disabeling vsync in openarena (where is an option to do so). I probably should ask on IRC or something
              to give the answer from IRC:
              (12:41:30) suokko: vsync is not on but dri2 defaults to tear free rendering
              (12:41:50) suokko: That means that dri2 doesn't update screen when scanout is reading the location that has to be updated
              (12:42:12) suokko: Which results about to vsync for full screen applications
              (12:42:43) suokko: At least for radeon there is no simple option to disable that yet

              Comment


              • #17
                Originally posted by NSLW View Post
                What I want is the best performance on Fedora 11, and i suspect that FBO is required for that. In my reasoning glxgears shows how well card performs. Card have considerably more fps in Ubuntu so Ubuntu is better or maybe shouldn't I look at fps value during my comparison?
                Looking at fps is fine, but do it with a workload similar to what you really want to do with the card. Run a game in benchmark mode or something... that way you have a better chance of getting numbers which will be meaningful.

                What you are seeing here is that as drivers become more sophisticated it's not unusual for them to run faster on complex real-world tasks but slower on artificial, simple tasks. The glxgears program is a classic "artificial, simple task" where more of the time is spent doing clears and buffer swaps than doing 3D drawing, and the DRI2 drivers aren't as fast as DRI1 on those operations. They are slower on other workloads as well (due to being new and un-optimized), but over time I think you will see performance on real-world apps increase out of proportion to performance on apps like glxgears.

                There is also the issue mentioned just above - that the DRI2 code includes some tear-free support which also reduces the frame rate a bit but improves your overall experience.

                So... I guess there are three separate issues here :

                - newness of the DRI2 stack (this will improve with time, but not so much with things like glxgears)
                - design of the stack shifting performance profile from "being fast at simple stuff" to "being fast at complex stuff"
                - no way yet to turn off the tear-free stuff and trade performance for tearing like DRI1
                Last edited by bridgman; 09-20-2009, 10:51 AM.

                Comment


                • #18
                  Originally posted by NSLW View Post
                  In my reasoning glxgears shows how well card performs. Card have considerably more fps in Ubuntu so Ubuntu is better or maybe shouldn't I look at fps value during my comparison?
                  Otherwise you're exactly right except you shouldn't be reading fps from glxgears but, like bridgman recommended, from some game you play. glxgears framerates are utterly uninteresting for everyone except apparently free3d guys. (which is why I recommended not reading that site, they give silly ideas)

                  Comment


                  • #19
                    In fairness the free3d site was most active a few years ago when it was harder to find real world apps you could run across a broad range of drivers. It does desperately need to be updated though...

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      In fairness the free3d site was most active a few years ago when it was harder to find real world apps you could run across a broad range of drivers. It does desperately need to be updated though...
                      I tried. It's run by people who refuse to budge a bit in changing the site and are firm believers in that glxgears fps is meaningful. Better just avoid it altogether.

                      Comment

                      Working...
                      X