Quoting Tvrtko Ursulin (2018-07-20 16:13:14) > > On 20/07/2018 11:19, Chris Wilson wrote: > > +/* > > + * Once upon a time we supposed that writes through the GGTT would be > > + * immediately in physical memory (once flushed out of the CPU path). > > However, > > + * on a few different processors and chipsets, this is not necessarily the > > case > > + * as the writes appear to be buffered internally. Thus a read of the > > backing > > + * storage (physical memory) via a different path (with different physical > > tags > > + * to the indirect write via the GGTT) will see stale values from before > > + * the GGTT write. Inside the kernel, we can for the most part keep track > > of > > + * the different read/write domains in use (e.g. set-domain), but the > > assumption > > + * of coherency is baked into the ABI, hence reporting its true state in > > this > > + * parameter. > > + * > > + * If set to true, writes via mmap_gtt are immediately visible following an > > + * lfence to flush the WCB. > > + * > > + * If set to false, writes via mmap_gtt are indeterminatnly delayed in an > > in > > + * internal buffer and are _not_ immediately visible to third parties > > accessing > > + * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC > > + * communications channel when set to false is strongly disadvised. > > I would perhaps change the language from "set to true/false" to > "reported as true/false".
s/set/reported/ and pushed. Thanks for the reviews, -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
