On Wed, 29 Oct 2003 11:43:43 +0000 Keith Whitwell <[EMAIL PROTECTED]> wrote:
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.
Very bad - consider gears, which can render a frame in 1/1000 sec. If it then locks the hardware to wait for vblank, it will end up locking the hardware almost all the time (because it is almost always waiting for vblank), and no other 3d apps nor the X server will be able to get it.
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.
That's straightforward to solve - you just put the app to sleep until the interrupt arrives. You have to do this already, right?
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.
The original DRM did dma this way, the gamma still does. It's slow and complex.
You don't need to go all the way though, as there's no need to rearrange multiple dma queues - just submit stuff to the engine in the same order it comes in, with the exception of swapbuffer commands on a software-simulated high-priority command queue. I imagine that while this will be faster & less complex than the original DRM mechanisms, it will still be somewhat painful.
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?
Not at all - there's the experiment of simulating a high-priority command queue as above, plus the option of real high-priority queues on Intel hardware.
Further, I disagree that waiting for 3D idle and then vblank is feasible, as it will lock out other users from the hardware for the majority of the time.
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
