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.
You don't want to shut the entire dma engine down waiting for vblank as this would kill performance with >1 3d application, or even where 2d apps and a single 3d app are mixed.
Some hardware has support for interrupting the main command stream with a higher priority one - the Intel i810 and i830 definitely allow this. In those, you could issue the swapbuffer commands to the high-priority ringbuffer when you receive the vblank interrupt, but allow other applications to continue submitting commands to the low-priority buffer. Of course, you'd need some mechanism to get uptodate cliprect information into the kernel.
You can imagine other mechanisms for supporting this in hardware - a delayed flipbuffer command that only works during vblank period, for example. But in general, I think you've got to have hardware support of some sort to make this work efficiently in the general case.
Keith
------------------------------------------------------- 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
