Some explanation is in order, although I'm not sure how to begin, so I'll dive right in.
When you're doing PCI transactions (same for AGP, etc.), and either the master or target device is "slow", the slow one can insert wait states. These are dead cycles on the bus where no data is transferred, but the transaction is held open. Now, according to the PCI standard, if the target is going to wait for a long time, it can request a "retry", but it doesn't have to, and even if it does, it doesn't help when you're doing PIOs because the only thing that CAN happen at that time is for the chipset to immediately retry.
Now, in the case of a GPU, there's often a FIFO where you're writing rendering commands, and you can often write commands faster than they're executed, so the fifo fills. Most GPUs provide a way to request that the PCI bus be throttled when you try to PIO to a full fifo.
Some graphics driver writers figured out that in some circumstances, you can get better performance out of the GPU if you just blindly write to the fifo. Rather than checking to make sure there's enough space, they just let the PCI hardware do it. The problem is that while a write is pending, NOTHING ELSE CAN USE THE BUS. It's completely tied up by the transaction with the GPU, and the length of time for the wait is unbounded, because the GPU could be processing something very time-consuming.
So, first of all, our design won't suffer from this. I'm not even planning on adding the OPTION of throttling. If you write to a full fifo, the result is undefined (well, it'll be defined, but you just won't like the result).
The next problem has to do with non-throttled transactions hogging the bus. When performing a transaction, even without wait states, you can tie up the bus for long periods of time. This happens more with DMA than with PIO, because if you preempt a thread that's doing PIO, its bus transactions get preempted also (well, indirectly). But DMA is controlled by the peripheral, and it can bend the rules. The way we deal with this will be to keep transactions lengths down. I'll give a fairly wide range of allowed transaction limits, but in testing, we'll have community members test against scenarios involving things like audio, and whenever there's a complaint about heavy graphics causing an audio glitch, we just knock down the transaction length until it's okay again.
On Apr 4, 2005 12:03 PM, Lourens Veen <[EMAIL PROTECTED]> wrote:
During some random surfing (actually, I know nothing about music and limit
myself to listening, but it's quite amazing how audio on GNU/Linux is
developing...) I found this paragraph at http://ardour.org/requirements.php:
"Video adapters are often a chronic weakspot for a digital audio workstation.
Sometimes this is caused by poor hardware design, sometimes by poor device
driver design (in turn caused by lack of information from the manufacturer),
and sometimes by both of these factors. The central problem tends to be
over-aggressive hogging of the PCI bus - the video interface and/or its
device driver believes that it is the most important hardware on the bus, and
prevents other hardware (e.g. your audio interface) from using it for
excessive periods of time."
Given that we are bus-speed-limited, we may have to be careful to avoid this.
Any thoughts?
Lourens
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
