On Thu, 21 Apr 2011 09:30:10 +0200 Arnd Bergmann arnd@arndb.de wrote:
On Wednesday 20 April 2011 23:52:56 Rebecca Schultz Zavin wrote:
The android team's graphics folks, the their counterparts at intel, imagination tech, nvidia, qualcomm and arm have all told me that they need a method for mapping buffers uncached to userspace. The common case for this is to write vertexes, textures etc to these buffers once and never touch them again. This may happen several (or even several 10s or more) of times per frame. My experience with cache flushes on ARM architectures matches Marek's.
Ok, thanks for the confirmation on that, both of you.
Is the requirement only to have the uncached mapping in user space then while it does not need to be mapped into the kernel, or is there also a requirement to map the same buffers into the kernel address space?
We like to be able to write to buffers mapped into userspace, preferably with a write combine attribute, for write mostly data like vertices, textures, and other state buffers. On Intel at least, we may end up binding objects at a different address than when the client ran before, so we have a relocation pass that fixes up address handles passed in by userspace, and that happens in kernel space, so we need a mapping there once userspace is done with the buffers and has dispatched the rendering command buffer.
But the main issue here is to avoid the overhead of repeated cache flushes. If the graphics stack is doing its job right, it shouldn't generally be reading gfx memory, so making sure the fast path just deals with already uncached pages is important. In some cases (e.g. software fallback or input detection on transformed objects) reading back from the render target is unavoidable, but those aren't the steady state, fast path cases we want to optimize for.