This seams like a no brainer to me. The Xserver! It would be a good place to intercept vblanks, if it dosen't allready, and connects to clients and card any way. A little more beef for the "?2d driver? or X server" to keep track of pending swaps for all dri clients, but if it were GLX it would be doing that any way.
--- Ian Romanick <[EMAIL PROTECTED]> wrote: > 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... ;) > __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com ------------------------------------------------------- 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
