XVideoTextureSyncToVBlank, xorg high cpu
Hi, I've been trying to eliminate some tearing on rendered YUV frames. I'm using SDL to render them to a YUV overlay, and couldn't find a decent way to sync draws with the vertical retrace (vsync). I thought I'd finally found the answer when I came across XVideoTextureSyncToVBlank as a setting inside the nvidia-settings tool, and indeed it did fix the tearing (none of the other X sync oriented settings seemed to make any difference). Then the problem reared it's ugly head...
When running just one rendering task at a time, it worked ok, but it quickly killed performance when I started doing more than one. The symptom is that the X server would start climbing to higher and higher CPU usage, for example, with XVideoTextureSyncToVBlank=0, xorg cpu usage with one overlay going would be < 2%. With it =0 and 8 windows going, it would still be under 10% or so. But with XVideoTextureSyncToVBlank=1, it would be maybe 20% for one, but would climb over the course of a few seconds from 40 or to 95+ for 2 or more, and would be basically be unusable for any more than 1 or 2 windows. I've seen this happen across recent nvidia driver releases (87.56 and 97.46 at least) and across a wide range of distributions, X versions, and kernels, both 32 and 64 bit.
I'm wondering why, and whether there is another way to get vsync functionality via the X and XVideo type functions used by SDL, or if not, perhaps a suggestion for an alternate rendering approach (as two extremes, I've considered both GL and DirectFB - wasn't sure about hardware assisted YUV support for either though).
Also, as a heads up to anyone else that may be affected - perhaps MythTV users, mplayer folks, etc., it looks like the default of XVideoTextureSyncToVBlank has been changed from 0 to 1 in the latest drivers (97.46), so this might start hitting more people. You can change it back with nvidia-settings -a XVideoTextureSyncToVBlank=0 but then of course, you may get tearing again.
Thanks for any explanations, help, etc.