Dnia 17-03-2005, czw o godzinie 02:55 -0500, Timothy Miller napisał(a): > Going on the assumption that the ring buffer is under the control of > the kernel and/or a privileged process that will follow a strict set > of rules, I have an idea. > > Usually, processes will request access to the ring buffer via IOCTL, > which inserts into the ring buffer an indirect DMA request to execute > commands in another set of buffers. That means that the memory > management of the ring buffer is under centralized software control. > That means that that software can do whatever it wants, right? > > Ok, how about this idea: When the kernel code determines that a given > ring-buffer page is about to fill, it automatically inserts into that > buffer a command that directs the DMA engine to fetch from a different > physical address. This 'link' would then allow the kernel to 'chain' > physical pages indefinitely. >
That's very similar to how Sony's playstation2 handles ring buffer. Basically DMA transfers are split into logical chunks and each chunk has a header telling where is next data chunk and next header. There are two modes "Destination Chain" and "Source Chain", the difference is where headers are located (source or destination memory). You may take a look at ps2 implementation, I may have missed some details but maybe you can find more info on www.playstation2-linux.com and www.ps2dev.org. There are also quite detailed specs provided with Sony's Playstation2 Linux kit. And generally I like the idea. ;) > The only disadvantage I can see is that it would be more complex to > determine where the GPU 'read pointer' is so as to know which pages > are no longer in use. But it's really not THAT complicated, and there > are numerous advantages, such as being able to dynamically grow/shrink > the ring buffer and reuse consumed pages in random order. > > There are still some kinks to work out, but what do you think? > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) -- Jacek Rosik <[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)
