From: Miguel F. <mi...@ce...> - 2002-09-22 20:15:20
|
On Sun, 2002-09-22 at 15:49, Fredrik Noring wrote: > I'd like to have efficient synchronisation integrated in the > XFree86 DGA drivers. Another idea is letting the hardware to do the flip. i don't know about nv, but i was told that at least matrox and ati cards have some registers that could automaticaly sync the flip with the next blank period. regards, Miguel PS: since you are talking about nvidia drivers the message below might be useful. From: Mark Vojkovich <MVo...@nv...> To: H}kan Hjort <d95...@dt...> Cc: ma...@nv..., xin...@li... Subject: Re: Re: [xine-devel] Xine + XvMC Date: 26 Jun 2002 13:20:14 -0700 On Wed, 26 Jun 2002, H}kan Hjort wrote: > > And, to be more precise, even the Xv drivers support it - there is custom > > XV_DOUBLEBUFFER and similar xv parameters for nvidia and ati cards. > > But this form of support is pure hack - there should be a standard way to > > enable it, or just enable it by default - as no one wants to disable it... > > It's enabled by default in all the NVIDIA drivers and should be in all hardware that support buffer queuing. A problem is that some cheap hardware can't double buffer so the only way to sync to the retrace is to program the overlay only during the blanking. In a userspace app without kernel support that means you have to spin in the X-server. This just doesn't work very well as there's no guarantee that you'll even be scheduled at that time and you typically eat most of the CPU doing that. It's just not worth it if the hardware can't double buffer. > When we have you attention and XV_DOUBLE_BUFFER is on the subject. > > We have some weird issues with it in Ogle. If it's enabled then you > get a really bad picture that jumps backwards/forwards in time and > tears. (I think you get the front/back buffers messed up somehow). > Switching it off (setting it to 0) make it all go away. This seems to > happen on really fast machines 1.7GHz with the latest NVIDIA drivers. > It not just a fluke either, have heard about this from at least four > different sources. This will only happen if you send frames quicker than the retrace. When the driver has already collected as many flips as the hardware can queue, it has two choices: spin until the next buffer is free, or forget about syncing to the retrace and overwrite one of the pending buffers. XFree86 drivers have mostly settled on the second behavior to avoid performance problems due to spinning. This is a simple driver modification to change this. In the "nv" driver in NVPutImage uncomment the part that looks like: #if 0 /* I have my reservations about this */ if(pPriv->doubleBuffer) { RIVA_HW_INST *pRiva = &(pNv->riva); int mask = 1 << (pPriv->currentBuffer << 2); while(pRiva->PMC[0x00008700/4] & mask); } #endif But, of course, the X-server will now burn the CPU any time you send frames quicker than the retrace. We could change over to this method for the default case if people are OK with the consequences of the CPU burn. I could sched_yield in that loop to reduce the CPU burn, but note that you'll likely get rescheduled and won't come back for a long time. So you have 3 choices when the client sends more buffers than the hardware can queue. 1) Forget about syncing to the retrace and overwrite a pending buffer. 2) Burn the CPU until the next buffer is free. 3) Get rescheduled and display this frame some time in the distant future, but at least you're not shearing and not eating CPU. Pick one. Mark. |