All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>, fei.yang@intel.com
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Chris Wilson <chris.p.wilson@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Andi Shyti <andi.shyti@linux.intel.com>,
	rohan.garg@intel.com, Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation
Date: Mon, 22 May 2023 08:25:33 -0700	[thread overview]
Message-ID: <168476913389.1509813.15102550159463496187@jljusten-skl> (raw)
In-Reply-To: <ZGtXmBh42oLIxcyi@ashyti-mobl2.lan>

On 2023-05-22 04:52:56, Andi Shyti wrote:
> Hi,
> 
> On Thu, May 18, 2023 at 10:11:03PM -0700, fei.yang@intel.com wrote:
> > From: Fei Yang <fei.yang@intel.com>
> > 
> > To comply with the design that buffer objects shall have immutable
> > cache setting through out their life cycle, {set, get}_caching ioctl's
> > are no longer supported from MTL onward. With that change caching
> > policy can only be set at object creation time. The current code
> > applies a default (platform dependent) cache setting for all objects.
> > However this is not optimal for performance tuning. The patch extends
> > the existing gem_create uAPI to let user set PAT index for the object
> > at creation time.
> > The new extension is platform independent, so UMD's can switch to using
> > this extension for older platforms as well, while {set, get}_caching are
> > still supported on these legacy paltforms for compatibility reason.
> > 
> > Test igt@gem_create@create_ext_set_pat posted at
> > https://patchwork.freedesktop.org/series/117695/
> > 
> > Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > 
> > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > Tested-by: Jordan Justen <jordan.l.justen@intel.com>
> 
> last call for comments and reviews on this patch. If nothing
> comes I am going to push it tomorrow morning (Europe).
> 
> There is also a merge request from Mesa pending on this so that I
> don't want to keep it hanging any longer.

No need to wait any longer with regard to feedback from Mesa.

I definitely was hoping for more consideration of the userspace
request, but it's been decisively rejected. My ack was not readily
given, but it stands.

-Jordan

WARNING: multiple messages have this Message-ID (diff)
From: Jordan Justen <jordan.l.justen@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>, fei.yang@intel.com
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation
Date: Mon, 22 May 2023 08:25:33 -0700	[thread overview]
Message-ID: <168476913389.1509813.15102550159463496187@jljusten-skl> (raw)
In-Reply-To: <ZGtXmBh42oLIxcyi@ashyti-mobl2.lan>

On 2023-05-22 04:52:56, Andi Shyti wrote:
> Hi,
> 
> On Thu, May 18, 2023 at 10:11:03PM -0700, fei.yang@intel.com wrote:
> > From: Fei Yang <fei.yang@intel.com>
> > 
> > To comply with the design that buffer objects shall have immutable
> > cache setting through out their life cycle, {set, get}_caching ioctl's
> > are no longer supported from MTL onward. With that change caching
> > policy can only be set at object creation time. The current code
> > applies a default (platform dependent) cache setting for all objects.
> > However this is not optimal for performance tuning. The patch extends
> > the existing gem_create uAPI to let user set PAT index for the object
> > at creation time.
> > The new extension is platform independent, so UMD's can switch to using
> > this extension for older platforms as well, while {set, get}_caching are
> > still supported on these legacy paltforms for compatibility reason.
> > 
> > Test igt@gem_create@create_ext_set_pat posted at
> > https://patchwork.freedesktop.org/series/117695/
> > 
> > Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > 
> > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
> > Cc: Matt Roper <matthew.d.roper@intel.com>
> > Cc: Andi Shyti <andi.shyti@linux.intel.com>
> > Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
> > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > Tested-by: Jordan Justen <jordan.l.justen@intel.com>
> 
> last call for comments and reviews on this patch. If nothing
> comes I am going to push it tomorrow morning (Europe).
> 
> There is also a merge request from Mesa pending on this so that I
> don't want to keep it hanging any longer.

No need to wait any longer with regard to feedback from Mesa.

I definitely was hoping for more consideration of the userspace
request, but it's been decisively rejected. My ack was not readily
given, but it stands.

-Jordan

  reply	other threads:[~2023-05-22 15:25 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19  5:11 [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation fei.yang
2023-05-19  5:11 ` [Intel-gfx] " fei.yang
2023-05-19  5:11 ` [PATCH v10 1/2] drm/i915/mtl: end support for set caching ioctl fei.yang
2023-05-19  5:11   ` [Intel-gfx] " fei.yang
2023-05-19  5:11 ` [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation fei.yang
2023-05-19  5:11   ` [Intel-gfx] " fei.yang
2023-05-21  4:30   ` Jordan Justen
2023-05-21  4:30     ` [Intel-gfx] " Jordan Justen
2023-05-25 11:42     ` Extension detection by enumeration vs attempt to use extension (Was: Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation) Joonas Lahtinen
2023-05-25 11:42       ` [Intel-gfx] Extension detection by enumeration vs attempt to use extension (Was: " Joonas Lahtinen
2023-05-22 11:52   ` [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation Andi Shyti
2023-05-22 11:52     ` [Intel-gfx] " Andi Shyti
2023-05-22 15:25     ` Jordan Justen [this message]
2023-05-22 15:25       ` Jordan Justen
2023-05-22 15:30       ` Andi Shyti
2023-05-22 15:30         ` [Intel-gfx] " Andi Shyti
2023-05-19  5:53 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Allow user to set cache at BO creation (rev10) Patchwork
2023-05-19  6:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-05-19 10:44 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-05-23  8:37 ` [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation Andi Shyti
2023-05-23  8:37   ` Andi Shyti
2023-05-24 11:56   ` Tvrtko Ursulin
2023-05-24 11:56     ` Tvrtko Ursulin
2023-05-24 12:05     ` Tvrtko Ursulin
2023-05-24 12:05       ` Tvrtko Ursulin
2023-05-24 12:19     ` Andi Shyti
2023-05-24 12:19       ` Andi Shyti
2023-05-24 12:30       ` Andi Shyti
2023-05-24 12:30         ` Andi Shyti
2023-05-24 12:52         ` Tvrtko Ursulin
2023-05-24 12:52           ` Tvrtko Ursulin
2023-05-24 12:34       ` Tvrtko Ursulin
2023-05-24 12:34         ` Tvrtko Ursulin

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=168476913389.1509813.15102550159463496187@jljusten-skl \
    --to=jordan.l.justen@intel.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=chris.p.wilson@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fei.yang@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    --cc=rohan.garg@intel.com \
    --cc=tvrtko.ursulin@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.