From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] lib/rendercopy_gen9: Set rw domains to zero for GEN12
Date: Thu, 28 Nov 2019 12:58:36 +0200 [thread overview]
Message-ID: <20191128105836.GC10209@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <157493758442.31435.13175629793228140545@skylake-alporthouse-com>
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
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-11-28 10:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 9:12 [igt-dev] [PATCH i-g-t] lib/rendercopy_gen9: Set rw domains to zero for GEN12 Mika Kahola
2019-11-28 9:16 ` Chris Wilson
2019-11-28 10:32 ` Imre Deak
2019-11-28 10:39 ` Chris Wilson
2019-11-28 10:45 ` Kahola, Mika
2019-11-28 10:58 ` Imre Deak [this message]
2019-11-28 10:24 ` [igt-dev] ✗ GitLab.Pipeline: warning for " Patchwork
2019-11-28 11:08 ` Petri Latvala
2019-11-28 12:50 ` Arkadiusz Hiler
2019-11-28 10:39 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2019-11-29 15:14 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191128105836.GC10209@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=igt-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox