On Tue, Apr 19, 2011 at 4:37 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
On Tue, Apr 19, 2011 at 2:23 PM, Arnd Bergmann arnd@arndb.de wrote:
This may be a stupid question, but do we have an agreement that it is actually a requirement to have uncached mappings? With the streaming DMA mapping API, it should be possible to work around noncoherent DMA by flushing the caches at the right times, which probably results in better performance than simply doing noncached mappings. What is the specific requirement for noncached memory regions?
That was my original plan, but our graphics folks and those at our partner companies basically have me convinced that the common case is for userspace to stream data into memory, say copying an image into a texture, and never read from it or touch it again. The alternative will mean a lot of cache flushes for small memory regions, in and of itself this becomes a performance problem. I think we want to optimize for this case, rather than the much less likely case of read-modify-write to these buffers.
This was why I made the comment earlier about wanting fault handlers for these buffers, so we could track if the buffer is dirty, and potentially what parts of the buffer are dirty.. so in the optimal case where no sw is touching the buffer, you don't incur the penalty, but also at the same time you still get decent performance in case where userspace does want to touch the buffer. So I think in most cases where people are scared of cached, it is actually quite ok.
That said, in case of tiled buffers on o4, because of the virtual -> tiled physical -> physical address translation that goes on, some small distance of prefetch might be touching something far away.. or in hyperspace.. there are ways to deal with that so I am not ready to rule out cached.. but I'm a bit less comfortable with cached for these type of buffers without spending some time to think it through.. (we avoided the issue so far by just making them uncached).
BR, -R