I'd like to discuss / revisit what it will take to implement asynchronous swapping. By this I mean glXSwapBuffers returns immediately even if the driver needs to wait several frames (due to the swap interval or whatever) to actually do the swap.
I've thought of a couple ways to do this, but they all have issues. Perhaps other people can think of some alternatives?
- Implement the wait in the kernel. The driver calls a new swap ioctl that takes the 'target' frame as a parameter. The kernel mainains a queue of pending swaps that is checked each time a vblank interrupt is handled. A mechanism for the driver to determine if the swap had actually happened would also be need.
I don't like this method because it would make it more difficult to add support for gang-swapping (i.e., GLX_SGIX_swap_group).
- 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.
I don't like this method for two reasons. First, it requires the use of a signal from a library without the knowledge of the application. That's pretty evil. Second, I don't think the driver could dispatch the swap (or do much else useful) from the signal handler.
- 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.
I think I like this option the best, but using an extra thread just feels wrong. At the same time, it would be easy to encapsulate all of the knowledge about when to perform a swap in that extra thread.
All of these options would require extra logic in the driver to prevent rendering operations (but certain state-changes should be okay?) while a swap was pending. 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... ;)
------------------------------------------------------- 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_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
