Bug 808765 - gnome-shell plus llvmpipe is too slow for simple dynamic graphics
gnome-shell plus llvmpipe is too slow for simple dynamic graphics
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
17
i386 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-31 12:41 EDT by John Reiser
Modified: 2013-07-31 13:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 13:42:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
edited strace.out of 1 second of gnome-shell with gnome-system-monitor running (18.61 KB, text/plain)
2012-03-31 13:30 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2012-03-31 12:41:46 EDT
Description of problem: When graphics is rendered by llvmpipe, then gnome-shell is too slow for simple dynamic graphics.  The strip charts in gnome-system-monitor take about 97% of CPU time on 1.6GHz Pentium-4 (Northwood) with Radeon 9250 (pci 1002:5960; [RV280]).  /usr/bin/top (with nothing else running) shows CPU time of 6% gnome-shell and 2% Xorg.  Dragging a Terminal window (move pointer to title bar, press and hold Button1, move pointer in circle (3cm diameter, 1Hz frequency)) shows noticeable lag: the window position trails the pointer by 0.3 seconds or more.  Typing characters into the shell prompt in a Terminal window shows lag at 5 characters per second (60 words per minute.)

In contrast, XFCE4 gives good performance with llvmpipe.  The strip charts of System Monitor show 5% to 7% CPU utilization.  /usr/bin/top by itself in a Terminal shows 0.3% CPU with Xorg also at 0.3%.  Dragging a terminal window shows no discernible lag.  Typing into a shell prompt in Terminal displays each character with a latency of less than 0.1 second.


Version-Release number of selected component (if applicable):
gnome-shell-3.4.0-1.fc17.i686
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)
mesa-dri-drivers-8.0.1-9.fc17.i686
xorg-x11-server-Xorg-1.12.0-2.fc17.i686
xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17.i686
xfce4-session-4.8.3-1.fc17.i686
kernel-PAE-3.3.0-8.fc17.i686


How reproducible: every time


Steps to Reproduce:
1. Force llvmpipe rendering, but do not enable Gnome3 fallback mode.  In my case, "mv /usr/lib/dri/r200_dri.so $HOME" as root, which disables "native" rendering.
2. Login to GNOME, observe simple dynamic graphics [unobscured, opaque (1==alpha; no transparency)] as in Description: gnome-system-monitor by itself; /usr/bin/top by itself in a Terminal; typing into shell prompt in Terminal.
3. Get XFCE: "yum groupinstall XFCE" as root.  Log out; log back in to an Xfce session (choose in ">Session" prompt in same dialog as Password), observe simple dynamic graphics.
  
Actual results: gnome-shell plus llvmpipe is too slow.  XFCE4 plus llvmpipe is more than good enough.


Expected results: gnome-shell plus llvmpipe is usable for simple dynamic graphics.


Additional info: There may be room for improvement (say, up to 20% or so) in the low-level sse2 code of the compositor.  However, a much larger improvement probably is possible in the strategy chosen by gnome-shell.  The strip charts of gnome-system-monitor are about 25% or less of the total area, yet strace of gnome-shell suggests that the whole pixmap is being transferred at each update.  Also, the strip chart overlays are 99% pixel-blt; at each update then only a narrow column at the right is new.  When dragging a Terminal window, only the shadow _outside_ the window changes; again, pixel-blt inside the graphics card handles the vast majority of the work.
Comment 1 John Reiser 2012-03-31 13:30:36 EDT
Created attachment 574224 [details]
edited strace.out of 1 second of gnome-shell with gnome-system-monitor running

Start gnome-system-monitor while using llvmpipe.  Then in a Terminal invoke:
  $ strace -tt -o strace.out -p $(pidof gnome-shell)
Wait a few seconds, then stop strace with SIGINT (^C).

I edited the output to isolate 1 second of time (1 update cycle of gnome-system-monitor).  I collapsed 2041 consecutive calls to "read(19,":
-----
09:59:06.360432 read(19, "\10\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0strace.out\0\0\0\0\0\0"..., 1024) = 64
09:59:06.360605 read(19, "\10\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0strace.out\0\0\0\0\0\0", 1024) = 32
09:59:06.360753 read(19, "\10\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0strace.out\0\0\0\0\0\0", 1024) = 32
-----

and 2042 consecutive calls to "gettimeofday(".:
-----
09:59:06.711130 gettimeofday({1333213146, 711187}, NULL) = 0
09:59:06.711286 gettimeofday({1333213146, 712106}, NULL) = 0
09:59:06.712224 gettimeofday({1333213146, 712284}, NULL) = 0
-----

The resulting trace file has 182 lines, 19052 total bytes.  I hope it is small enough to be usable, yet large enough to be useful.
Comment 2 John Reiser 2012-03-31 14:23:44 EDT
Same results for Apple Macintosh Mini (Core Duo, i686 only [not x86_64, which would be Core 2 Duo]), "bogomips	: 3333.50" with:
  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) [pci 8086:27a2]
not using native i915_dri.so, but using llvmpipe instead.

gnome-system-monitor by itself shows 85% to 90% CPU utilization on _each_ CPU. Adding /usr/bin/top shows gnome-shell at 145% to 150% CPU, Xorg at 20%.

/usr/bin/top by itself gets 7% to 8% CPU, with Xorg at 1.7%.

Dragging a Terminal window shows lag.  Typing into shell prompt shows latency, although less than Radeon 9250 with Pentium-4.
Comment 3 Owen Taylor 2012-04-05 15:41:48 EDT
If entire-window pixmap transfers are done when a client updates part of a window, that would be a problem with the llvmpipe implementation of DRI, not gnome-shell. Reassigning to Mesa.
Comment 4 John Reiser 2012-04-06 12:10:57 EDT
glxgears on this box, using current updates-testing .rpms:

[without r200_dri.so: glxinfo | grep renderer]
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)

[with    r200_dri.so: glxinfo | grep renderer]
OpenGL renderer string: Mesa DRI R200 (RV280 5960)  TCL DRI2

[gnome-shell(fallback mode), no r200_dri.so]
Visually, gears do not spin.  They jerk a few frames at a time:
1, or 2, or 10 or so, etc.; sometimes "backwards".
The image appears to change at slightly less than 2 Hz.
$ glxgears
230 frames in 5.0 seconds = 45.953 FPS
274 frames in 5.0 seconds = 54.745 FPS
274 frames in 5.0 seconds = 54.789 FPS
272 frames in 5.0 seconds = 54.377 FPS
280 frames in 5.0 seconds = 55.823 FPS
273 frames in 5.0 seconds = 54.403 FPS

[Xfce session, no r200_dri.so]
Gears spin normally, claiming about 90 FPS.
FPS decreases to about  55 when dragging (3cm diameter @1Hz.)
FPS increases to about 100 upon obscuring the top half.
$ glxgears
396 frames in 5.0 seconds = 79.111 FPS
415 frames in 5.0 seconds = 82.896 FPS
452 frames in 5.0 seconds = 90.313 FPS
454 frames in 5.0 seconds = 90.738 FPS
453 frames in 5.0 seconds = 90.429 FPS
454 frames in 5.0 seconds = 90.798 FPS
455 frames in 5.0 seconds = 90.874 FPS
382 frames in 5.0 seconds = 76.267 FPS
272 frames in 5.0 seconds = 54.315 FPS
271 frames in 5.0 seconds = 54.135 FPS
273 frames in 5.0 seconds = 54.521 FPS
425 frames in 5.0 seconds = 84.910 FPS
440 frames in 5.0 seconds = 87.833 FPS
503 frames in 5.0 seconds = 100.419 FPS
503 frames in 5.0 seconds = 100.572 FPS
503 frames in 5.0 seconds = 100.431 FPS
493 frames in 5.0 seconds = 98.502 FPS

[gnome-shell(fallback mode), with r200_dri.so]
Gears spin normally, at 60 FPS while static, and when dragged,
and partially obscured.
$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.401 FPS
301 frames in 5.0 seconds = 60.005 FPS
301 frames in 5.0 seconds = 60.005 FPS
299 frames in 5.0 seconds = 59.737 FPS
301 frames in 5.0 seconds = 60.038 FPS
300 frames in 5.0 seconds = 59.839 FPS
301 frames in 5.0 seconds = 60.005 FPS
301 frames in 5.0 seconds = 60.005 FPS

[Xfce session, with r200_dri.so]
Gears spin normally, at 60 FPS while static, and when dragged,
and partially obscured.
$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
301 frames in 5.0 seconds = 60.099 FPS
301 frames in 5.0 seconds = 60.005 FPS
301 frames in 5.0 seconds = 60.005 FPS
299 frames in 5.0 seconds = 59.793 FPS
301 frames in 5.0 seconds = 59.823 FPS
301 frames in 5.0 seconds = 60.194 FPS
300 frames in 5.0 seconds = 59.806 FPS


[rpm]
gnome-shell-3.4.0-1.fc17.i686
kernel-PAE-3.3.1-3.fc17.i686
mesa-debuginfo-8.0.2-2.fc17.i686
mesa-dri-drivers-8.0.2-2.fc17.i686
mesa-dri-filesystem-8.0.2-2.fc17.i686
mesa-libGL-8.0.2-2.fc17.i686
mesa-libglapi-8.0.2-2.fc17.i686
mesa-libGLES-8.0.2-2.fc17.i686
mesa-libGLU-8.0.2-2.fc17.i686
xfce4-session-4.8.3-1.fc17.i686
xorg-x11-drv-ati-6.14.4-2.20120329gitde2419e55.fc17.i686
xorg-x11-server-Xorg-1.12.0-2.fc17.i686

[lspci, lspci -n]
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
01:00.0 0300: 1002:5960 (rev 01)
01:00.1 0380: 1002:5940 (rev 01)

[memtest86+-4.20]
Pentium 4 (0.13)   1614 MHz
L1 Cache:     8K  12138 MB/s
L2 Cache:   512K  10551 MB/s
L3 Cache:   None
Memory  :  1024M    847 MB/s
Chipset : Intel i845 (ECC: Disabled) / FSB: 100MHz

[/proc/cpuinfo]
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Pentium(R) 4 CPU 1.60GHz
stepping	: 4
microcode	: 0x1e
cpu MHz		: 1600.000
cache size	: 512 KB
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up pebs bts
bogomips	: 3228.51
Comment 5 Fedora End Of Life 2013-07-03 15:20:43 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 6 Fedora End Of Life 2013-07-31 13:42:19 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.