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 <mic...@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 <mic...@daenzer.net> wrote: >>>> From: Michel Dänzer <michel.daen...@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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
