All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenneth Graunke <kenneth@whitecape.org>
To: Matthew Auld <matthew.auld@intel.com>,
	Jason Ekstrand <jason@jlekstrand.net>
Cc: "Lionel Landwerlin" <lionel.g.landwerlin@linux.intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Jordan Justen" <jordan.l.justen@intel.com>,
	"Intel GFX" <intel-gfx@lists.freedesktop.org>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Daniele Ceraolo Spurio" <daniele.ceraolospurio@intel.com>,
	"Jon Bloomfield" <jon.bloomfield@intel.com>,
	"ML mesa-dev" <mesa-dev@lists.freedesktop.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI
Date: Wed, 28 Apr 2021 10:12:12 -0700	[thread overview]
Message-ID: <8049200.4jvIBUede8@mizzik> (raw)
In-Reply-To: <CAOFGe95sNTYu3YSZf7eP16ssz=goMVxtoZx2yKiY9xJMS7A3Ew@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]

On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld <matthew.auld@intel.com> wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
> 
> In Vulkan on non-LLC platforms, we only enable snooping for things
> that are going to be mapped: staging buffers, state buffers, batches,
> etc.  For anything that's not mapped (tiled images, etc.) we leave
> snooping off on non-LLC platforms so we don't take a hit from it.  In
> GL, I think it works out to be effectively the same but it's a less
> obvious decision there.
> 
> --Jason

iris currently enables snooping on non-LLC platforms when Gallium marks
a resource as PIPE_USAGE_STAGING, which generally means it's going to be
mapped and "fast CPU access" is desired.  Most buffers are not snooped.

I don't believe i965 uses snooping at all, surprisingly.

--Ken

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Kenneth Graunke <kenneth@whitecape.org>
To: Matthew Auld <matthew.auld@intel.com>,
	Jason Ekstrand <jason@jlekstrand.net>
Cc: "Lionel Landwerlin" <lionel.g.landwerlin@linux.intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Intel GFX" <intel-gfx@lists.freedesktop.org>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"ML mesa-dev" <mesa-dev@lists.freedesktop.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI
Date: Wed, 28 Apr 2021 10:12:12 -0700	[thread overview]
Message-ID: <8049200.4jvIBUede8@mizzik> (raw)
In-Reply-To: <CAOFGe95sNTYu3YSZf7eP16ssz=goMVxtoZx2yKiY9xJMS7A3Ew@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 959 bytes --]

On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld <matthew.auld@intel.com> wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
> 
> In Vulkan on non-LLC platforms, we only enable snooping for things
> that are going to be mapped: staging buffers, state buffers, batches,
> etc.  For anything that's not mapped (tiled images, etc.) we leave
> snooping off on non-LLC platforms so we don't take a hit from it.  In
> GL, I think it works out to be effectively the same but it's a less
> obvious decision there.
> 
> --Jason

iris currently enables snooping on non-LLC platforms when Gallium marks
a resource as PIPE_USAGE_STAGING, which generally means it's going to be
mapped and "fast CPU access" is desired.  Most buffers are not snooped.

I don't believe i965 uses snooping at all, surprisingly.

--Ken

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-04-29  5:49 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-26  9:38 [PATCH 1/9] drm/doc/rfc: i915 DG1 uAPI Matthew Auld
2021-04-26  9:38 ` [Intel-gfx] " Matthew Auld
2021-04-26  9:38 ` [PATCH 2/9] drm/i915: mark stolen as private Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-26  9:38 ` [PATCH 3/9] drm/i915/query: Expose memory regions through the query uAPI Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-26  9:38 ` [PATCH 4/9] drm/i915: rework gem_create flow for upcoming extensions Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-26  9:38 ` [PATCH 5/9] drm/i915/uapi: introduce drm_i915_gem_create_ext Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-26  9:38 ` [PATCH 6/9] drm/i915/uapi: implement object placement extension Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-28 17:28   ` Kenneth Graunke
2021-04-28 17:28     ` [Intel-gfx] " Kenneth Graunke
2021-04-26  9:38 ` [PATCH 7/9] drm/i915/lmem: support optional CPU clearing for special internal use Matthew Auld
2021-04-26  9:38   ` [Intel-gfx] " Matthew Auld
2021-04-26 12:53   ` kernel test robot
2021-04-26 14:03   ` kernel test robot
2021-04-26  9:39 ` [PATCH 8/9] drm/i915/gem: clear userspace buffers for LMEM Matthew Auld
2021-04-26  9:39   ` [Intel-gfx] " Matthew Auld
2021-04-26  9:39 ` [PATCH 9/9] drm/i915/gem: hide new uAPI behind CONFIG_BROKEN Matthew Auld
2021-04-26  9:39   ` [Intel-gfx] " Matthew Auld
2021-04-26 12:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/doc/rfc: i915 DG1 uAPI Patchwork
2021-04-26 12:18 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-04-26 12:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-04-26 15:11 ` [PATCH 1/9] " Jason Ekstrand
2021-04-26 15:11   ` [Intel-gfx] " Jason Ekstrand
2021-04-26 15:31   ` Matthew Auld
2021-04-26 15:31     ` [Intel-gfx] " Matthew Auld
2021-04-26 16:25     ` Jason Ekstrand
2021-04-26 16:25       ` [Intel-gfx] " Jason Ekstrand
2021-04-26 16:32       ` Daniel Vetter
2021-04-26 16:32         ` [Intel-gfx] " Daniel Vetter
2021-04-26 15:13 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] " Patchwork
2021-04-28 15:16 ` [PATCH 1/9] " Kenneth Graunke
2021-04-28 15:16   ` [Intel-gfx] " Kenneth Graunke
2021-04-28 16:10   ` Matthew Auld
2021-04-28 16:10     ` [Intel-gfx] " Matthew Auld
2021-04-28 15:51 ` Jason Ekstrand
2021-04-28 15:51   ` [Intel-gfx] " Jason Ekstrand
2021-04-28 16:41   ` Matthew Auld
2021-04-28 16:41     ` [Intel-gfx] " Matthew Auld
2021-04-28 16:56     ` Jason Ekstrand
2021-04-28 16:56       ` [Intel-gfx] " Jason Ekstrand
2021-04-28 17:12       ` Kenneth Graunke [this message]
2021-04-28 17:12         ` Kenneth Graunke
2021-04-28 17:30 ` Kenneth Graunke
2021-04-28 17:30   ` [Intel-gfx] " Kenneth Graunke
2021-04-28 17:39 ` Bloomfield, Jon
2021-04-28 17:39   ` [Intel-gfx] " Bloomfield, Jon

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=8049200.4jvIBUede8@mizzik \
    --to=kenneth@whitecape.org \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=jon.bloomfield@intel.com \
    --cc=jordan.l.justen@intel.com \
    --cc=lionel.g.landwerlin@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=thomas.hellstrom@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.