On 8/20/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
If you have submitted a bunch of GPU commands (because you didn't have any more to submit), and then part way through the process of DMAing those commands, you decide you want to send more, how do you tell the GPU to fetch those new commands?
With current hardware there is only one command stream and you have to wait until it finishes. With DX10 there are multiple command streams. The commands are usually written into VRAM using shared memory access. The GPU reads them from VRAM and avoid the PCI bus. You can use tricks like making the last command a loop. Write you new commands somewhere else in memory. Then use shared VRAM access to modify the loop instruction with a single memory write. It can be done safely. DMA is primarily used for image transfer.
> DMA to/from the cards is overrated. Most apps load their textures into > the card and then never use DMA again. DX10 specs virtual VRAM which > eliminates even more need for programmed DMA. Only a few apps read > textures back from the card. I'm concerned rather less about image loads (although I want to use DMA for that too) than I am about using DMA to send rendering commands, because I don't want to keep the CPU busy during the relatively slow process of transferring commands across the bus. I want the CPU busy doing something unrelated, another thing that will give us an advantage over other cards.
ASFAIK all of the chips can read the commands from VRAM or system memory. Don't forget about the problem of cache coherency with the CPU. If you write the commands into system memory that memory has to be flushed out of the CPU cache. That can be slower than just writing to VRAM to being with. This reminds me, I haven't seen any mention of GART/AGP technology. The internal GPU DMA engine depends on that to make system memory appear in it's internal address space. The GPU DMA engine always runs with internal addresses, if those addresses end up in the internally mapped AGP area they turn into PCI bus ops. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
