On 18.07.2014 13:45, Marek Olšák wrote:
If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the patch is okay.
Apart from correctness, I still wonder how this will affect performance, most notably CPU reads. This change unconditionally uses write-combined, uncached memory for MAP_COHERENT buffers. Unless I am missing something, CPU reads will be slow, even if the buffer storage flags indicate that the buffer will be read by the CPU. Maybe it's a good idea to avoid write combined memory if the buffer storage flags include MAP_READ_BIT?
Grigori
Marek
On Fri, Jul 18, 2014 at 5:19 AM, Michel Dänzer michel@daenzer.net wrote:
On 17.07.2014 21:00, Marek Olšák wrote:
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer michel@daenzer.net wrote:
From: Michel Dänzer michel.daenzer@amd.com
This is hopefully safe: The kernel makes sure writes to these mappings finish before the GPU might start reading from them, and the GPU caches are invalidated at the start of a command stream.
The resource flags actually tell you what you can do. If the COHERENT flag is set, the mapping must be cached.
Why is that required? As I explain above, we should satisfy the requirements of the ARB_buffer_storage extension AFAICT.
As pointed out by you and Grigori in other posts, I should probably just drop the special treatment of persistent mappings though, so the placement and flags are derived from the buffer usage.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev