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. :)

> - 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.


> 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?

> 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?

> 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'? :)


-- 
Earthling Michel DÃnzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
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

Reply via email to