On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:

> On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
> > 
> > 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.
> 
> FWIW, flips can be asynchronous on Radeons, but then there's the
> possibility of rendering to the backbuffer not being finished yet...

But that doesn't work with multiple clients.

> 
> > 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?
> 
> Radeons do have two streams, but they're not strictly about high and low
> priority. We use the primary stream for the ring buffer and the
> secondary for indirect buffers. It might be interesting to explore
> whether driving the primary in push/PIO mode would allow to handle this
> better, and what if any impact it would have on overall performance.

If the two streams are not about priority, are they processed in
parallel? Is it necessary to use the secondary stream for indirect
buffers or could they go to the primary stream as well? In that case we
could keep the secondary stream mostly idle and only use it for low
latency swapping.

Felix


-------------------------------------------------------
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_id70&alloc_id638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to