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

[Kahola, Mika]

On Thu, 2019-11-28 at 10:39 +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.
> -Chris
Ok, let's ignore this patch and carry on with clear color.

-Mika-