On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
- Keep the queue of pending swaps in the user-space driver. Add an ioctl for the kernel to deliver a signal to the app / driver when a specified vblank has occured.
FWIW, that wouldn't need to be added, it's been in place for a while. :)
Oh yeah. I totally forgot about that. :)
- Keep the queue of pending swaps in the user-space driver. Spawn a second thread that *only* performs swaps. It blocks on a futuex or similar the gets uped each time a vblank occurs. When the required vblank has happend, it calls the existing ioctl to perform the swap.
Nothing would need adding here either, just use the vblank ioctl in the default blocking mode.
That would work as long as swaps are always request in strictly increasing vblank order. With some of the swap extensions, such as OML_sync_control, that may not always be the case.
All of these options would require extra logic in the driver to prevent
rendering operations (but certain state-changes should be okay?)
Anything that doesn't actually emit stuff to the hardware I guess?
Some stuff, like uploading textures, should be okay. Dunno.
while a swap was pending.
One idea would be a 'swapPending' flag; it would be set when a swap gets scheduled, and when it's set, any attempt at emitting stuff to the hardware would block using the vblank ioctl. Unless I'm missing something, this should work in either the 3D driver or the DRM, but the latter would probably be better?
I was thinking of just using a mutex. When a swap is pending the swap-thread holds the mutex. When the other thread wants to emit something to the hardware, it tries to get the mutex.
Some of this could be mitigated by implementing triple buffering for windows & pbuffers, but that would require per-window backbuffers and a bunch of other stuff. Actually, given enough memory, each time a swap happened the driver could just allocate a new backbuffer to render to. When the swap happened the old backbuffer would be freed. Nevermind that tangent for now... ;)
Can you say 'runaway rendering'? :)
Well... :) You'd want to limit how many frames ahead rendering could get. I think one of the swap related extensions might even allow apps to specify this, but I don't remember for sure.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
