Calling synchronous XvShmPutImage or XvPutImage faster than vblank causes client starvation.
Submitted by Gary Scharf
Assigned to Xorg Project Team
Description
Bug Report: XvShmPutImage and XvPutImage
--------[Keywords:]------- XvShmPutImage XvPutImage "resource contention" /tmp/.X11-unix/X0
-------------[Summary: ]------------
Calling XvShmPutImage or XvPutImage above some critical frequency causes resource contention on /tmp/.X11-unix/X0, resulting in user noticeable poor performance. In our environment, 60Hz is above the critical frequency.
------------[Software Environment:]--------------
X -version
X.Org X Server 1.6.3 Release Date: 2009-7-31 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.28-xxx_pancake-r2 i686 Current Operating System: Linux localhost 2.6.28-xxx_pancake-r2 #2 SMP PREEMPT Thu Jun 18 12:21:56 EDT 2009 i686 Build Date: 07 August 2009 01:47:57PM
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) Textured Video"
-----------------[Hardware Environment]------------------
Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz GenuineIntel GNU/Linux Intel® Graphics Media Accelerator 4500
zigs of ram/ HD, etc
------------[Symptoms]-----------------
Various applications that interact with X show poor performance when XvShmPutImage or XvPutImage are called at high frequencies.
It appears that there is some contention for /tmp/X11-unix/X0 that did not occur with earlier releases.
Strace: read(3, 0x3f8e201c, 32) = -1 EAGAIN (Resource temporarily unavailable)
These contention events scale linearly with the frequency at which these functions are called. I used the test case below to plot some neat graphs. ;)
At a fixed frequency of call, it also scales linearly with the overall number of pixels being drawn.
------------[History]-----------------
This problem was initially discovered uncovered through diagnosing the poor performance of wmctrl and other X lib programs in an upgraded X environment when operating in the presence of tvtime, which by default calls XvShmPutImage at 60 Hz.
The problem was confirmed to not exist with previous versions of X and XV, and also shown to exist outside of the tvtime/wmctrl combination. We were also able to demonstrate that calling those functions at 30 Hz, the nominal frame rate of most video applications falls below some threshold of user imperceptibility.
---------[Test Case]---------
Preparations: Download http://bellet.info/XVideo/testxv.c (Found on wikipedia: http://en.wikipedia.org/wiki/XVideo) Compile: "gcc -o testxv testxv.c -L/usr/X11R6/lib -lX11 -lXext -lXv"
Download & install wmctrl: http://en.wikipedia.org/wiki/Wmctrl
Demonstrate contention: Execute: ./testxv 2>/dev/null& Count contention events: strace wmctrl -l | grep EAGAIN | wc -l (normally counts 51-60 contention events)
Demonstrate vastly reduced/eliminated contention: Q&D alteration to testxv to throttle framerate:
insert at line 293, before "frames++; usleep(1000000/30);
Compile: "gcc -o testxv testxv.c -L/usr/X11R6/lib -lX11 -lXext -lXv"
Execute: ./testxv 2>/dev/null& Count contention events: strace wmctrl -l | grep EAGAIN | wc -l (normally counts 0-4 contention events, with occasional spikes to 40 or so.)
Version: 7.4 (2008.09)