I'd prefer the kernel implementation. If you do the swapping in user-space you require a context switch to each client that needs to swap. However, you need to react to the vblank interrupt as fast as possible in order to finish the swap during the vertical retrace.
If that turns out to be too complicated then the user-space thread would be my second choice. Using a signal is not really an option IMHO. I've been thinking about this before and I got stuck at a more practical problem. Maybe my thoughts are a bit Radeon-centric though. The problem is that you have rendering commands queued in the ring buffer. When the vblank IRQ occurs you want to swap immediately. So you can't put the swap commands (blits, whatever) on the same command queue. That would delay the swap for an unspecified time and make the whole procedure useless. We discussed this before and it was concluded that there needs to be some sort of high priority command queue. IIRC certain hardware (was it i8xx?) has such a high priority queue. Is there a good way to implement one in software if the hardware doesn't have such an extra queue? My idea was to build some sort of scheduler for the GPU into the DRM that would never fill up much of the hardware command queue. Then it could squeeze in higher priority commands without much delay. A full blown scheduler for the GPU sounds like overkill to me though. Does anyone have a simpler idea? Regards, Felix On Mon, 08 Mar 2004 20:28:55 -0800 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... ;) > > > > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
