public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Kahola, Mika" <mika.kahola@intel.com>
To: "Deak, Imre" <imre.deak@intel.com>,
	"chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>
Cc: "igt-dev@lists.freedesktop.org" <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 10:45:45 +0000	[thread overview]
Message-ID: <34b9a182afa0550a2f8274b4b2b89e61f6b5b5ba.camel@intel.com> (raw)
In-Reply-To: <157493758442.31435.13175629793228140545@skylake-alporthouse-com>

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-

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-11-28 10:45 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 [this message]
2019-11-28 10:58       ` Imre Deak
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=34b9a182afa0550a2f8274b4b2b89e61f6b5b5ba.camel@intel.com \
    --to=mika.kahola@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=imre.deak@intel.com \
    /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