Dose most DACs have dublebuffering or do you realy only have from the start of the vtrace to the end to do your update? If you can having from the start of the vtrace untill the end of the next vtrace todo your swaping is optimal.
- If you only have one FB. Pad each, or some, commands with enuff nops to be replaced by a goto or jmp. Then when you need to run something replace the nops with a jmp. This workes well when the commands are not bigger then bus size. You would think it would crash since you would be changing data while it's being run, but infact since a jmp command in asm is so small it gets run or it dosent. Also you could just overright part of the command it the queue and put the saved copy back in aftewards. - Estamate when you will need todo the swap and put in an endless loop. Break the loop when you need todo the swap. If you miss every now and then it won't be then end of the world. Most good estamations will be in the mits of rendering commands for a future fram any way, since this is when this will be used. --- Felix Kühling <[EMAIL PROTECTED]> wrote: > 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-develceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel __________________________________ 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
