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 at 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 at daenzer.net> >>> wrote: >>>> From: Michel D?nzer <michel.daenzer at 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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140718/25c84a2b/attachment.sig>
