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.)