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

[Chris Wilson]

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