On Thu, Aug 14, 2008 at 01:15:58PM +0300, Petri Hintukainen wrote:
to, 2008-08-14 kello 11:25 +0200, Thomas Hilber kirjoitti:
Does the Xserver poll for some resources not available or something?
Maybe the driver is waiting for free overlay buffer ? Some drivers wait for free hardware overlay buffer in simple busy loop.
a good idea, but in the case of 'xserver-xorg-video-ati' true hardware double buffers are supported. If a new PutImage() comes in the DDX simply toggles to the other double buffer and starts to write there. No matter this buffer ever has been completely read by CRT controller.
So there is no mechanism waiting here for something as far as I can see.
Usually this can be seen only when video player draws Xv frames faster than the actual output rate (ex. displaying 50p video with 50p display mode).
To see the effect in practice I just set the VGA frame rate to several values slightly below 50Hz (i.e. in the range 49.94 - 49.99HZ). Applying all these 'low' frame rates lead to dropped fields as expected. But Xserver %CPU always stays around 2%CPU maximum.
The only exception here is if I press the 'OK' button. The OSD 'time-shift' bar showing up then costs about 16%CPU. Strangely enough if I open the 'recordings' OSD which covers almost the entire screen this takes only about 6%CPU.
BTW: my xineliboutput OSD setup is as follows:
xineliboutput.OSD.AlphaCorrection = 0 xineliboutput.OSD.AlphaCorrectionAbs = 0 xineliboutput.OSD.Downscale = 1 xineliboutput.OSD.ExtSubSize = -1 xineliboutput.OSD.HideMainMenu = 0 xineliboutput.OSD.LayersVisible = 0 xineliboutput.OSD.Prescale = 1 xineliboutput.OSD.SpuAutoSelect = 0 xineliboutput.OSD.UnscaledAlways = 0 xineliboutput.OSD.UnscaledLowRes = 0 xineliboutput.OSD.UnscaledOpaque = 0
But anyway all these values still are in the 'green area' and are compensated by the patch.
A value of 40%CPU as Gavin posted above I never could reproduce on my system. There must be broken something.
Cheers Thomas