Hi list, I've been thinking about ways to implement a combined "wait for vblank and buffer swap" operation. But somehow I can't get the pieces together partly because I have a pretty vague understanding what the hardware does or can do on a low level.
First a short summary of the problem. Currently the user space driver waits for a vblank and then issues a buffer swap ioctl. That ioctl puts the actual swap instructions on the command queue of the 3D hardware. After that it may take an arbitrary time before the swap is actually executed depending on how many rendering instructions were pending in the queue when the swap was issued. Therefore you can observe tearing even with vsyncing enabled. A simple and stupid workaround is to do something equivalent to glFinish before waiting for the next vblank. This way the application has to wait a lot. With an ideal solution the application wouldn't have to wait at all, though it could wait for a certain buffer swap to complete. The OML_sync_control extension spec describes this in much detail. Here is one possible way to do this, though I'm not sure it is actually possible to do with real hardware ;-): The 3D engine finishes rendering a frame. Then it generates an interrupt. At this point the engine has to suspend _somehow_ until the buffer swap has completed. The kernel waits for the software interrupt. If the deadline for the frame has passed it executes a buffer swap immediately. Otherwise it also waits for a specified vblank interrupt and then executes the buffer swap. When the swap is completed it _somehow_ makes the 3D engine resume executing rendering commands for the next frame. "_somehow_" marks the places I'm not sure about. Could someone comment on this please? Even if this is all crap, maybe you have a better idea. Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
