On Wed, 29 Oct 2003 11:43:43 +0000 Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote: > > 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. Yeah, if one 3D app waits for a vblank all others would have to wait too. That's bad. > > 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. A delayed flipbuffer command doesn't give the level of control you need to implement OML_sync_control. A high priority queue alone doesn't solve the problem either. The application mustn't put rendering commands for the next frame on the low priority queue until the swap has actually happened. Some sort of scheduler for the 3D engine in the kernel could be a solution even without hardware support. However, that would be a huge project as state management related to context switches that is now done in user space would have to move the kernel. So is the conclusion that the only feasible way to do vsyncing in the short term is to make the application wait for 3D idle and then for the vblank? > > Keith 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
