GL_MAP_READ_BIT is always unconditionally set for glBufferData, which is the most-used function. However, st/mesa can look at the immutability flag to distinguish between BufferData and BufferStorage before pipe_buffer_create is called, and set the read flag if the caller is BufferStorage and GL_MAP_READ_BIT is flagged, and not set any flag otherwise. Marek On Fri, Jul 18, 2014 at 9:50 PM, Grigori Goronzy <greg@xxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxx> wrote: >>> On 17.07.2014 21:00, Marek Olšák wrote: >>>> On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >>>>> From: Michel Dänzer <michel.daenzer@xxxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
