Bug 27069

Summary: OpenGl is slower on dri2
Product: DRI Reporter: Dymchenko Bogdan <dmbohdan>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg of the r200 machine
none
Xorg.log of the r200 machine
none
glxinfo from the r200 machine none

Description Dymchenko Bogdan 2010-03-14 07:13:34 UTC
Hi. I want to report that OpenGl applications is slower when dri2 and kms enabled. When it was disabled glxgears showed 1100 FPS, but now it show 568 FPS. 
I`ve tested it on real opengl apptication - epsxe (emulator of playstation 1) and when dri2 enabled it show 33 fps. With dri it show over 60 FPS. 

I don`t know about other videocard, i`ve tested this on my Radeon X1300
Comment 1 Stefan Dösinger 2010-03-15 04:12:49 UTC
Just for the record, I can confirm this issue here as well. DRI2 barely runs etracer on my Radeon 9000 mobility, with the dri1 code it runs at 200+ fps. Similar results on my r500 card.
Comment 2 Alex Deucher 2010-03-15 09:52:18 UTC
this is likely a dup of bug 26599.  The slow down is at least partially caused by the anti-tearing code used for buffer swaps.
Comment 3 Stefan Dösinger 2011-09-01 16:20:12 UTC
This problem still exists, UMS(as far as 3D is still working with it) is much faster than KMS. Unfortunately the only app that's still working with UMS in Mesa 7.11 is glxgears.

On my r250 GPU glxgeares runs at 2600 fps with UMS, 1070 with KMS(default Window size). At 1400x1050 the numbers are 370 fps(UMS) and 60 fps(KMS).

I don't think vsync causes the issue, disabling it seems to work fine, at least for windowed apps.

etracer is still a lot slower with KMS than it used to be. At 1400x1050 and otherwise default settings it runs at 15-20 fps. With an ancient Mesa version I tested today(6.4.2) it runs at a pretty okish 60 fps at the same settings.

The problem seems to be on the GPU side. Whenever the problem occurs the CPU is idle and the GPU working, and increasing the rendering resolution makes the problem worse. The unfortunate situation this creates is that the 6 years old Mesa on my old hard drive vastly outperforms Mesa 7.11 in many rendering situations.

I could not spot any CPU side problems, but the GPU slowness makes it hard to test. My unscientific guess is that in setups where the KMS GPU slowness doesn't matter Mesa 7.11 is about 50% faster than Mesa 6.4.2. (etracer with a tiny resolution, long view range and lots of objects)

I'll test r300 on a Radeon X1600 GPU over the weekend. This GPU/driver combo is pretty slow as well, but I'm not sure if r300 still supports UMS.
Comment 4 Stefan Dösinger 2011-09-01 16:21:54 UTC
(In reply to comment #3)
> This problem still exists,
I forgot to add the usual software version info:

Kernel: 3.0.4-gentoo
Xorg: X.Org X Server 1.10.2
DDX: xf86-video-ati-6.14.2
Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5)
Comment 5 Thierry Vignaud 2011-09-02 05:17:51 UTC
This is because output is maxed at screen refreshing and won't go over 60fps
Comment 6 Xavier Bestel 2011-09-02 06:11:01 UTC
That does not explain the 15-20 fps he sees with etracer.
Comment 7 Tom Stellard 2011-09-02 06:20:39 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > This problem still exists,
> I forgot to add the usual software version info:
> 
> Kernel: 3.0.4-gentoo
> Xorg: X.Org X Server 1.10.2
> DDX: xf86-video-ati-6.14.2
> Mesa: Mesa 7.11. (Also tried mesa git, revision db3a7c366b5)

Can you also post the output of dmesg and glxinfo, as well as your Xorg.log.
Comment 8 Alex Deucher 2011-09-02 06:49:43 UTC
UMS supported Colortiling and hyperZ on r1xx/r2xx asics and a few other features that haven't been implemented with KMS yet.  The information is available if someone wants to add support to KMS.  KMS also defaults to vsynced 3D.  r3xx and newer asics should be faster with KMS.
Comment 9 Stefan Dösinger 2011-09-03 11:45:25 UTC
I tested this on r300(g) with a Radeon X1600, and the results were inconclusive. UMS only ran glxgears resonably, and in fullscreen it always forced vsync on. r300g outperformed r300 in real apps(e.g. etracer).

However, the X1600 with r300g is a lot slower on the GPU side than it should be I think. I'll install a few games on Windows XP to verify this, and file a separate bug(or add infos to an existing bug report if one exists).
Comment 10 Stefan Dösinger 2011-09-03 11:48:02 UTC
Created attachment 50875 [details]
dmesg of the r200 machine
Comment 11 Stefan Dösinger 2011-09-03 11:50:12 UTC
Created attachment 50876 [details]
Xorg.log of the r200 machine

This file contains the following lines:
[    36.568] (II) RADEON(0): KMS Color Tiling: enabled
[    36.568] (II) RADEON(0): KMS Pageflipping: enabled

The man page says color tiling and page flipping are implemented on r200. I had to enable color tiling manually, but page flipping was on by default. Enabling color tiling didn't change the performance.
Comment 12 Stefan Dösinger 2011-09-03 12:09:05 UTC
Created attachment 50877 [details]
glxinfo from the r200 machine
Comment 13 Alex Deucher 2011-09-05 18:57:31 UTC
(In reply to comment #11)
> The man page says color tiling and page flipping are implemented on r200. I had
> to enable color tiling manually, but page flipping was on by default. Enabling
> color tiling didn't change the performance.

Support for colortiling is not implemented for r1xx or r2xx yet for KMS so enabling it does nothing.  KMS pageflipping is vsynced, so it won't really help with performance; it just reduces memory bandwidth for buffer swaps by pageflipping rather than blitting.
Comment 14 Marek Olšák 2014-01-23 11:50:00 UTC
I don't think this is still an issue. DRI2 OpenGL drivers have matured a lot, especially for the R300-R500 GPUs. It's unlikely that the drivers for older GPUs will be improved. Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.