On Thursday 24 February 2005 23:57, Daniel Phillips wrote: > On Thursday 24 February 2005 09:46, Timothy Miller wrote: > > Anyhow, each port will have its own very small cache. This way, > > accessing the same pixel twice does not require a re-read of memory. > > (Although the two texture units will share a port, I think I want to > > give each one its own cache.) > > Could you clarify please: each port has its own cache? And did you mean > "share each port" rather than "share a port"? > > > Caching with low overhead can result in non-coherency. Therefore, > > certain things like bitblts will need to be able to specify that the > > read caches are to be flushed before reading starts (and other > > similar things). > > Ugh, that sounds like a big mess. If the blit is a read then the read > cache does not need to be flushed, except we need to worry about > ordering between pixels written to the frame buffer and bitblt reads > from the frame buffer. Handling framebuffer blits separately from the > rendering pipeline is a huge race. > > WritePixels has to go through the pipeline in many cases anyway, so this > isn't a problem. We only have to worry about reads and raw writes. > The easy solution is to flush the whole pipeline, just for the case of > a raw blit to or from the framebuffer, don't you think? Otherwise, we > could keep track of the bounds of the current trapezoid and avoid > flushing in most cases, but that is a lot more work.
Flushing the whole pipeline isn't enough when there are independent read caches involved. Consider the following scenario: 1) We render some textured polygons. 2) The texture is updated (using TexSubImage or something) which results in a DMA upload. 3) We render some more textured polygons using the same texture. You are likely to get artifacts (i.e. rendering using the old instead of the new texture) if you don't invalidate the read caches. However, you're really overestimating the problem here. As far as I know, all graphics cards out there have separate caches and need to be instructed to do cache flushes sometimes. Heck, even an x86 CPU requires the kernel to issue manual cache flushes! And this really isn't a problem in practice (as long as the behaviour of the caches is documented well...). Just let Timothy design the hardware so that it makes the best use out of the available resources. If there is a limited amount of cache coherency management that has to be done by the driver, we can easily deal with that. cu, Nicolai
pgppdbO0vg8Lp.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
