[igt-dev] [PATCH i-g-t] lib/rendercopy_gen9: Set rw domains to zero for GEN12

[Imre Deak]

On Thu, Nov 28, 2019 at 10:39:44AM +0000, Chris Wilson wrote:
> Quoting Imre Deak (2019-11-28 10:32:05)
> > On Thu, Nov 28, 2019 at 09:16:20AM +0000, Chris Wilson wrote:
> > > Quoting Mika Kahola (2019-11-28 09:12:28)
> > > > GEN12 doesn't need read and write domains to be set. Let's set
> > > > these to zero in case of GEN12.
> > > 
> > > Why gen12? For the entire file the only bit that is significant is
> > > write_domain != 0
> > 
> > Err, that idea was mine, but then it was wrong. Mika needs to add a
> > relocation on this surface state to the color key data that's where this
> > change comes from.
> > 
> > Didn't think about the write domain being significant even on LLC
> > platforms, so let's just drop my idea for now (was only for clarity when
> > emitting relocations on GEN12) and use the same read/write domains as on
> > other platforms.
> > 
> > For reference could you explain how the write domain is signicant on LLC
> > platforms? (My guess now is that the kernel can wait for writes on the
> > surface to finnish, but it doesn't need it to flush caches, which is not
> > necessary on LLC.)
> 
> Every buffer passed to execbuf is put on a list of active buffers, so we
> do not discard memory being used by the GPU too early.
> 
> If you declare a buffer is written to by execbuf, a write hazard/fence
> is placed on that buffer in addition to the normal fence. The write into
> that buffer is then scheduled after all previous reads, and all future
> reads are performed after this write. Any user access to the buffer via
> GEM (gem_read, gem_set_domain) will also wait until the GPU write is
> complete before returning.
> 
> So the write_domain is significant for implicit ordering of operations.
> You can of course do everything with explicit fencing instead.

Ok makes sense now, thanks.

> -Chris