Bug#538810: video-radeon: direct rendering: graphics deceleration?
Do you still have this slowness with latest mesa packages, kernel and so on? Brice -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100306102651.ga30...@loulous.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/31 Michel Dänzer : > On Fri, 2009-07-31 at 10:29 +0200, Michal Suchanek wrote: >> 2009/7/31 Michel Dänzer : >> > On Fri, 2009-07-31 at 00:13 +0200, Michal Suchanek wrote: >> >> >> >> The next thing to try might be to install the drm modules that came >> >> with the mesa library. >> > >> > There's no such thing. If you mean drm-modules-source, that's deprecated >> > in favour of the DRM modules in the kernel. >> >> aren't the modules provided with mesa newer? > > If you mean git://anongit.freedesktop.org/git/mesa/drm (which isn't > really 'provided with Mesa', the repository is located there for > historical reasons), no. > > >> > BTW, what's the number of polys displayed by hypertorus? >> >> I have 2,080 polys. > > Okay, same here. I'm really stumped as to why it's so slow for you... > Just to add a few more data points: Radeon 9250 does about 5.5 fps (compared to the 8fps on x550) K8M800 integrated graphics does about 40 fps FireGL v3350 does about 120 fps I would expect that x550 is slightly faster than 9250 - it is in line with what I have seen so far but I am somewhat surprised that the K8M800 is so much faster. Looks like the Radeons are really inefficient at that particular demo for some reason. This is with current sid packages. Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/31 Michel Dänzer : > On Mon, 2009-07-27 at 10:33 +0200, Michal Suchanek wrote: >> >> DRM Information from dmesg: >> [ 0.004000] No AGP bridge found >> [ 0.410137] Linux agpgart interface v0.103 >> [ 1645.480173] [drm] Initialized drm 1.1.0 20060810 >> [ 1645.512336] [drm] Initialized radeon 1.30.0 20080528 for :04:00.0 on >> minor 0 >> [ 1646.044382] [drm] Setting GART location based on new memory map >> [ 1646.044825] [drm] Loading R300 Microcode >> [ 1646.118378] [drm] Num pipes: 1 >> [ 1646.118388] [drm] writeback test succeeded in 1 usecs >> [ 2170.778834] [drm] Num pipes: 1 >> [ 2334.790400] [drm] Setting GART location based on new memory map >> [ 2334.790834] [drm] Loading R300 Microcode >> [ 2334.843130] [drm] Num pipes: 1 >> [ 2334.843139] [drm] writeback test succeeded in 1 usecs > > Random idea: Does booting with > > radeon.no_wb=1 > > on the kernel command line make a difference? Please provide the output It does not, although it is a module option which is set on module load, not on boot so reloading the module suffices to change the option. > of > > dmesg|grep drm [ 223.166366] [drm] Initialized drm 1.1.0 20060810 [ 223.187861] [drm] Initialized radeon 1.30.0 20080528 for :04:00.0 on minor 0 [ 223.770776] [drm] Setting GART location based on new memory map [ 223.771205] [drm] Loading R300 Microcode [ 223.846356] [drm] Num pipes: 1 [ 223.846365] [drm] writeback test succeeded in 1 usecs [10871.723341] [drm] Num pipes: 1 [10880.790437] [drm] Num pipes: 1 [22430.631442] [drm] Num pipes: 1 [22444.914498] [drm] Num pipes: 1 [30242.895252] [drm] Num pipes: 1 [30261.480058] [drm] Num pipes: 1 [31216.570251] [drm] Num pipes: 1 [31243.129134] [drm] Num pipes: 1 [31270.667052] [drm] Num pipes: 1 [31273.821515] [drm] Num pipes: 1 [31514.631073] [drm] Num pipes: 1 [31525.323040] [drm] Module unloaded [31561.642888] [drm] Initialized radeon 1.30.0 20080528 for :04:00.0 on minor 0 [31610.450791] [drm] Setting GART location based on new memory map [31610.451236] [drm] Loading R300 Microcode [31610.531895] [drm] Num pipes: 1 [31610.531905] [drm] writeback test succeeded in 1 usecs [31610.531908] [drm] writeback forced off [33520.332727] [drm] Num pipes: 1 [33527.360151] [drm] Num pipes: 1 > > cat /sys/module/radeon/parameters/no_wb it has changed to 1 now > > when trying this. > > Also, if you have any /etc/drirc or ~/.drirc files, please provide them. I do not have these files. Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Mon, 2009-07-27 at 10:33 +0200, Michal Suchanek wrote: > > DRM Information from dmesg: > [0.004000] No AGP bridge found > [0.410137] Linux agpgart interface v0.103 > [ 1645.480173] [drm] Initialized drm 1.1.0 20060810 > [ 1645.512336] [drm] Initialized radeon 1.30.0 20080528 for :04:00.0 on > minor 0 > [ 1646.044382] [drm] Setting GART location based on new memory map > [ 1646.044825] [drm] Loading R300 Microcode > [ 1646.118378] [drm] Num pipes: 1 > [ 1646.118388] [drm] writeback test succeeded in 1 usecs > [ 2170.778834] [drm] Num pipes: 1 > [ 2334.790400] [drm] Setting GART location based on new memory map > [ 2334.790834] [drm] Loading R300 Microcode > [ 2334.843130] [drm] Num pipes: 1 > [ 2334.843139] [drm] writeback test succeeded in 1 usecs Random idea: Does booting with radeon.no_wb=1 on the kernel command line make a difference? Please provide the output of dmesg|grep drm and cat /sys/module/radeon/parameters/no_wb when trying this. Also, if you have any /etc/drirc or ~/.drirc files, please provide them. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/31 Michel Dänzer : > On Fri, 2009-07-31 at 00:13 +0200, Michal Suchanek wrote: >> 2009/7/30 Michel Dänzer : >> > On Thu, 2009-07-30 at 01:36 +0200, Michal Suchanek wrote: >> >> >> >> The majority of time is spent in: >> >> (with -fps) 181333 53.6798 radeon.ko radeon.ko >> >> radeon_do_wait_for_idle >> >> (without -fps) 287349 59.3526 radeon.ko radeon.ko >> >> radeon_freelist_get >> > >> > This indicates the GPU is the bottleneck, but I'm not sure why it would >> > be that slow... though one thing I notice now is that the card only has >> > a 64 bit wide memory bus, that could be the bottleneck. What kind of >> > numbers does >> > >> > x11perf -copywinwin500 -aa10text -repeat 1 >> > >> > give? (Preferably without a compositing manager running) >> > >> >> This is the output: >> >> x11perf - X11 performance program, version 1.2 >> The X.Org Foundation server version 10602901 on :0.0 >> from heretic >> Fri Jul 31 00:06:24 2009 >> >> Sync time adjustment is 0.1073 msecs. >> >> 320 reps @ 0.0018 msec (554000.0/sec): Char in 80-char aa line >> (Charter 10) >> >> 8000 reps @ 0.6963 msec ( 1440.0/sec): Copy 500x500 from window to >> window > > Okay, that's not much worse than here, so it seems like your hardware > should be capable of similar performance in hypertorus as well. > > >> The next thing to try might be to install the drm modules that came >> with the mesa library. > > There's no such thing. If you mean drm-modules-source, that's deprecated > in favour of the DRM modules in the kernel. aren't the modules provided with mesa newer? > > >> I would expect that like CPU operations the GPU operations can be >> optimized so a later code could have better results. > > Indeed, it certainly can't hurt to try upstream Mesa Git. > > >> Unfortunately. unlike Intel ATI did not hand out optimization manuals >> for their chips so there is not much hope in improving the >> performance. > > I'm not sure that's an accurate comparison of the documentation provided > by these vendors, but anyway I don't think the low performance of > hypertorus on your system is representative, there just seems to be > something weird going on there. > > BTW, what's the number of polys displayed by hypertorus? I have 2,080 polys. Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Fri, 2009-07-31 at 10:29 +0200, Michal Suchanek wrote: > 2009/7/31 Michel Dänzer : > > On Fri, 2009-07-31 at 00:13 +0200, Michal Suchanek wrote: > >> > >> The next thing to try might be to install the drm modules that came > >> with the mesa library. > > > > There's no such thing. If you mean drm-modules-source, that's deprecated > > in favour of the DRM modules in the kernel. > > aren't the modules provided with mesa newer? If you mean git://anongit.freedesktop.org/git/mesa/drm (which isn't really 'provided with Mesa', the repository is located there for historical reasons), no. > > BTW, what's the number of polys displayed by hypertorus? > > I have 2,080 polys. Okay, same here. I'm really stumped as to why it's so slow for you... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Fri, 2009-07-31 at 00:13 +0200, Michal Suchanek wrote: > 2009/7/30 Michel Dänzer : > > On Thu, 2009-07-30 at 01:36 +0200, Michal Suchanek wrote: > >> > >> The majority of time is spent in: > >> (with -fps) 181333 53.6798 radeon.koradeon.ko > >> radeon_do_wait_for_idle > >> (without -fps) 287349 59.3526 radeon.koradeon.ko > >> radeon_freelist_get > > > > This indicates the GPU is the bottleneck, but I'm not sure why it would > > be that slow... though one thing I notice now is that the card only has > > a 64 bit wide memory bus, that could be the bottleneck. What kind of > > numbers does > > > > x11perf -copywinwin500 -aa10text -repeat 1 > > > > give? (Preferably without a compositing manager running) > > > > This is the output: > > x11perf - X11 performance program, version 1.2 > The X.Org Foundation server version 10602901 on :0.0 > from heretic > Fri Jul 31 00:06:24 2009 > > Sync time adjustment is 0.1073 msecs. > > 320 reps @ 0.0018 msec (554000.0/sec): Char in 80-char aa line > (Charter 10) > >8000 reps @ 0.6963 msec ( 1440.0/sec): Copy 500x500 from window to > window Okay, that's not much worse than here, so it seems like your hardware should be capable of similar performance in hypertorus as well. > The next thing to try might be to install the drm modules that came > with the mesa library. There's no such thing. If you mean drm-modules-source, that's deprecated in favour of the DRM modules in the kernel. > I would expect that like CPU operations the GPU operations can be > optimized so a later code could have better results. Indeed, it certainly can't hurt to try upstream Mesa Git. > Unfortunately. unlike Intel ATI did not hand out optimization manuals > for their chips so there is not much hope in improving the > performance. I'm not sure that's an accurate comparison of the documentation provided by these vendors, but anyway I don't think the low performance of hypertorus on your system is representative, there just seems to be something weird going on there. BTW, what's the number of polys displayed by hypertorus? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/30 Michel Dänzer : > On Thu, 2009-07-30 at 01:36 +0200, Michal Suchanek wrote: >> >> The majority of time is spent in: >> (with -fps) 181333 53.6798 radeon.ko radeon.ko >> radeon_do_wait_for_idle >> (without -fps) 287349 59.3526 radeon.ko radeon.ko >> radeon_freelist_get > > This indicates the GPU is the bottleneck, but I'm not sure why it would > be that slow... though one thing I notice now is that the card only has > a 64 bit wide memory bus, that could be the bottleneck. What kind of > numbers does > > x11perf -copywinwin500 -aa10text -repeat 1 > > give? (Preferably without a compositing manager running) > This is the output: x11perf - X11 performance program, version 1.2 The X.Org Foundation server version 10602901 on :0.0 from heretic Fri Jul 31 00:06:24 2009 Sync time adjustment is 0.1073 msecs. 320 reps @ 0.0018 msec (554000.0/sec): Char in 80-char aa line (Charter 10) 8000 reps @ 0.6963 msec ( 1440.0/sec): Copy 500x500 from window to window The next thing to try might be to install the drm modules that came with the mesa library. I would expect that like CPU operations the GPU operations can be optimized so a later code could have better results. Unfortunately. unlike Intel ATI did not hand out optimization manuals for their chips so there is not much hope in improving the performance. Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Thu, 2009-07-30 at 01:36 +0200, Michal Suchanek wrote: > > The majority of time is spent in: > (with -fps) 181333 53.6798 radeon.koradeon.ko > radeon_do_wait_for_idle > (without -fps) 287349 59.3526 radeon.koradeon.ko > radeon_freelist_get This indicates the GPU is the bottleneck, but I'm not sure why it would be that slow... though one thing I notice now is that the card only has a 64 bit wide memory bus, that could be the bottleneck. What kind of numbers does x11perf -copywinwin500 -aa10text -repeat 1 give? (Preferably without a compositing manager running) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/28 Michel Dänzer : > On Tue, 2009-07-28 at 02:49 +0200, Michal Suchanek wrote: >> On 28/07/2009, Michel Dänzer wrote: >> > On Tue, 2009-07-28 at 00:16 +0200, Michal Suchanek wrote: >> > > On 27/07/2009, Michel Dänzer wrote: >> > > > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: >> > > > > 2009/7/27 Michel Dänzer : >> > > > > >> > > > > > >> > > > > > Please provide the full output of >> > > > > > >> > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 >> > > > > > >> > > > > > for both cases. >> > > > > > >> > > > > > For now assuming it's a 3D driver issue, reassigning. >> > > > > > >> > > > > >> > > > > Attaching output of glxinfo. >> > > > >> > > > >> > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage >> > > > compare when running >> > > > >> > > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps >> > > > >> > > > ? >> > > >> > > With DRI fps is pretty much constant around 8.0 >> > >> > >> > Hmm, that's pretty low, I'm getting around 40 fps on an RV350. >> >> It's no wonder it is slow. Even rendering by a Celeron CPU is at times >> faster than what my GPU shows. > > That's weird though, your GPU should be at least about as fast as mine. > > >> > > > BTW, you can force the swrast driver by setting the environment >> > variable >> > > > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. >> > > > >> > > >> > > With this option fps ranges from 7.5 to 12 depending on object view >> > angle. >> > > >> > > These are values in fullscreen and no delay. Both cause 100% system >> > > load but the DRI one causes system load and the software one causes >> > > user load. >> > >> > >> > It might be interesting to find out where the CPU time is spent with >> > hardware acceleration. >> > >> >> It might be another unrelated DRI problem because in >> xscreeensaver-demo the CPU is almost unused and the animation is still >> slow. It's actually quite interesting, though. Turning on the fps >> display makes the system time go almost 100% even in the demo. > > That may be because the 3D driver doesn't accelerate glBitmap(), so the > FPS text is rendered in software. > >> I wonder how I could find where the time is spent. If it is system >> time it is spent in kernel, right? > > E.g. oprofile can profile the kernel as well if it has access to the > uncompressed vmlinux binary. Which is not packaged by Debian nor is there a tool for extracting it from the compressed one. The majority of time is spent in: (with -fps) 181333 53.6798 radeon.koradeon.ko radeon_do_wait_for_idle (without -fps) 287349 59.3526 radeon.koradeon.ko radeon_freelist_get Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Tue, 2009-07-28 at 02:49 +0200, Michal Suchanek wrote: > On 28/07/2009, Michel Dänzer wrote: > > On Tue, 2009-07-28 at 00:16 +0200, Michal Suchanek wrote: > > > On 27/07/2009, Michel Dänzer wrote: > > > > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: > > > > > 2009/7/27 Michel Dänzer : > > > > > > > > > > > > > > > > > Please provide the full output of > > > > > > > > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > > > > > > > > > > > for both cases. > > > > > > > > > > > > For now assuming it's a 3D driver issue, reassigning. > > > > > > > > > > > > > > > > Attaching output of glxinfo. > > > > > > > > > > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage > > > > compare when running > > > > > > > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps > > > > > > > > ? > > > > > > With DRI fps is pretty much constant around 8.0 > > > > > > Hmm, that's pretty low, I'm getting around 40 fps on an RV350. > > It's no wonder it is slow. Even rendering by a Celeron CPU is at times > faster than what my GPU shows. That's weird though, your GPU should be at least about as fast as mine. > > > > BTW, you can force the swrast driver by setting the environment > > variable > > > > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. > > > > > > > > > > With this option fps ranges from 7.5 to 12 depending on object view > > angle. > > > > > > These are values in fullscreen and no delay. Both cause 100% system > > > load but the DRI one causes system load and the software one causes > > > user load. > > > > > > It might be interesting to find out where the CPU time is spent with > > hardware acceleration. > > > > It might be another unrelated DRI problem because in > xscreeensaver-demo the CPU is almost unused and the animation is still > slow. It's actually quite interesting, though. Turning on the fps > display makes the system time go almost 100% even in the demo. That may be because the 3D driver doesn't accelerate glBitmap(), so the FPS text is rendered in software. > I wonder how I could find where the time is spent. If it is system > time it is spent in kernel, right? E.g. oprofile can profile the kernel as well if it has access to the uncompressed vmlinux binary. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On 28/07/2009, Michel Dänzer wrote: > On Tue, 2009-07-28 at 00:16 +0200, Michal Suchanek wrote: > > On 27/07/2009, Michel Dänzer wrote: > > > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: > > > > 2009/7/27 Michel Dänzer : > > > > > > > > > > > > > > Please provide the full output of > > > > > > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > > > > > > > > > for both cases. > > > > > > > > > > For now assuming it's a 3D driver issue, reassigning. > > > > > > > > > > > > > Attaching output of glxinfo. > > > > > > > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage > > > compare when running > > > > > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps > > > > > > ? > > > > With DRI fps is pretty much constant around 8.0 > > > Hmm, that's pretty low, I'm getting around 40 fps on an RV350. It's no wonder it is slow. Even rendering by a Celeron CPU is at times faster than what my GPU shows. > > > > > > BTW, you can force the swrast driver by setting the environment variable > > > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. > > > > > > > With this option fps ranges from 7.5 to 12 depending on object view angle. > > > > These are values in fullscreen and no delay. Both cause 100% system > > load but the DRI one causes system load and the software one causes > > user load. > > > It might be interesting to find out where the CPU time is spent with > hardware acceleration. > It might be another unrelated DRI problem because in xscreeensaver-demo the CPU is almost unused and the animation is still slow. It's actually quite interesting, though. Turning on the fps display makes the system time go almost 100% even in the demo. I wonder how I could find where the time is spent. If it is system time it is spent in kernel, right? Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On 27/07/2009, Michel Dänzer wrote: > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: > > 2009/7/27 Michel Dänzer : > > > > > > > > Please provide the full output of > > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > > > > > for both cases. > > > > > > For now assuming it's a 3D driver issue, reassigning. > > > > > > > Attaching output of glxinfo. > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage > compare when running > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps > > ? With DRI fps is pretty much constant around 8.0 > > BTW, you can force the swrast driver by setting the environment variable > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. > With this option fps ranges from 7.5 to 12 depending on object view angle. These are values in fullscreen and no delay. Both cause 100% system load but the DRI one causes system load and the software one causes user load. These are fullscreen values. The difference might be larger in the small demo in the xscreensaver-demo application. With software rendering the animation in demo seems smoother and 70% user load is generated. With DRI it causes a little load in system time. Thanks Michal -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Tue, 2009-07-28 at 00:16 +0200, Michal Suchanek wrote: > On 27/07/2009, Michel Dänzer wrote: > > On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: > > > 2009/7/27 Michel Dänzer : > > > > > > > > > > > Please provide the full output of > > > > > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > > > > > > > for both cases. > > > > > > > > For now assuming it's a 3D driver issue, reassigning. > > > > > > > > > > Attaching output of glxinfo. > > > > > > Thanks. I don't see anything wrong. How do the framerate and CPU usage > > compare when running > > > > /usr/lib/xscreensaver/hypertorus -delay 0 -fps > > > > ? > > With DRI fps is pretty much constant around 8.0 Hmm, that's pretty low, I'm getting around 40 fps on an RV350. > > BTW, you can force the swrast driver by setting the environment variable > > LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. > > > > With this option fps ranges from 7.5 to 12 depending on object view angle. > > These are values in fullscreen and no delay. Both cause 100% system > load but the DRI one causes system load and the software one causes > user load. It might be interesting to find out where the CPU time is spent with hardware acceleration. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
On Mon, 2009-07-27 at 21:14 +0200, Michal Suchanek wrote: > 2009/7/27 Michel Dänzer : > > > > > Please provide the full output of > > > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > > > for both cases. > > > > For now assuming it's a 3D driver issue, reassigning. > > > > Attaching output of glxinfo. Thanks. I don't see anything wrong. How do the framerate and CPU usage compare when running /usr/lib/xscreensaver/hypertorus -delay 0 -fps ? BTW, you can force the swrast driver by setting the environment variable LIBGL_ALWAYS_SOFTWARE=1 even when the DRI is enabled. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
2009/7/27 Michel Dänzer : > > Please provide the full output of > > LIBGL_DEBUG=verbose glxinfo 2>&1 > > for both cases. > > For now assuming it's a 3D driver issue, reassigning. > Attaching output of glxinfo. Thanks Michal radeon-dri.log Description: Binary data radeon-no-dri.log Description: Binary data
Processed: Re: Bug#538810: video-radeon: direct rendering: graphics deceleration?
Processing commands for cont...@bugs.debian.org: > reassign 538810 libgl1-mesa-dri Bug #538810 [xserver-xorg-video-radeon] video-radeon: direct rendering: graphics deceleration? Bug reassigned from package 'xserver-xorg-video-radeon' to 'libgl1-mesa-dri'. Bug #538810 [libgl1-mesa-dri] video-radeon: direct rendering: graphics deceleration? Bug No longer marked as found in versions xserver-xorg-video-ati/1:6.12.2-3. Bug #538810 [libgl1-mesa-dri] video-radeon: direct rendering: graphics deceleration? Ignoring request to alter fixed versions of bug #538810 to the same values previously set > kthxbye Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538810: video-radeon: direct rendering: graphics deceleration?
reassign 538810 libgl1-mesa-dri kthxbye On Mon, 2009-07-27 at 10:33 +0200, Michal Suchanek wrote: > Package: xserver-xorg-video-radeon > Version: 1:6.12.2-3 > Severity: normal > File: video-radeon > > > Hello > > The hypertorus (striped) xscreensaver demo seems slower with DRI. Sure, > it takes less cpu with direct rendering enabled but it seems much more > choppy. > > The non-striped version does not show this issue. It is always slow and > always takes lots of cpu time. Please provide the full output of LIBGL_DEBUG=verbose glxinfo 2>&1 for both cases. For now assuming it's a 3D driver issue, reassigning. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
