From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
fei.yang@intel.com
Cc: Arkadiusz Hiler <arek@hiler.eu>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Petri Latvala <adrinael@adrinael.net>,
Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [Intel-gfx] [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation
Date: Mon, 15 May 2023 11:20:39 +0100 [thread overview]
Message-ID: <6ebba088-68e3-3f6e-4ccc-f29ab5d66fa9@linux.intel.com> (raw)
In-Reply-To: <168392127300.1245490.15218496130423132985@jljusten-skl>
On 12/05/2023 20:54, Jordan Justen wrote:
> On 2023-05-10 15:14:16, Andi Shyti wrote:
>> Hi,
>>
>> On Tue, May 09, 2023 at 09:59:42AM -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.
>>>
>>> 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>
>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> just for a matter of completeness, this is new uapi is tested
>> through the "create-ext-set-pat" test case from the "gem_create"
>> igt test[1]. Can any of the igt maintainers give it a look,
>> comment and ack?
>>
>> The mesa merge request is here [2]. As there is a merge request
>> in progress, would anyone from mesa be so kind to give an ack to
>> this patch, as well?
>>
>> With the mesa ack in place this patch should be ready to go and
>> I'm looking forward to having it in.
>
> I tested my MR [2] in our CI. There was some bad news, but I don't
> think it needs to block these patches.
>
> The good news was that I found that OpenGL testing with our iris
> driver appeared to have ok results when using this interface.
>
> But, our Vulkan Anvil driver was not stable with the current patches
> in the Mesa MR. We will need to debug this further before using the
> interface on Vulkan.
>
> I don't suspect that this is an issue with the kernel interface, so
> you can add:
>
> Tested-by: Jordan Justen <jordan.l.justen@intel.com>
I had a browse through the Mesa merge request and it looks all r-b-ed to
me. To confirm - it will get merged when we merge the i915 half?
Could you also give an a-b for the i915 patch please?
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
fei.yang@intel.com
Cc: Arkadiusz Hiler <arek@hiler.eu>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Petri Latvala <adrinael@adrinael.net>,
Matt Roper <matthew.d.roper@intel.com>
Subject: Re: [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation
Date: Mon, 15 May 2023 11:20:39 +0100 [thread overview]
Message-ID: <6ebba088-68e3-3f6e-4ccc-f29ab5d66fa9@linux.intel.com> (raw)
In-Reply-To: <168392127300.1245490.15218496130423132985@jljusten-skl>
On 12/05/2023 20:54, Jordan Justen wrote:
> On 2023-05-10 15:14:16, Andi Shyti wrote:
>> Hi,
>>
>> On Tue, May 09, 2023 at 09:59:42AM -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.
>>>
>>> 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>
>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> just for a matter of completeness, this is new uapi is tested
>> through the "create-ext-set-pat" test case from the "gem_create"
>> igt test[1]. Can any of the igt maintainers give it a look,
>> comment and ack?
>>
>> The mesa merge request is here [2]. As there is a merge request
>> in progress, would anyone from mesa be so kind to give an ack to
>> this patch, as well?
>>
>> With the mesa ack in place this patch should be ready to go and
>> I'm looking forward to having it in.
>
> I tested my MR [2] in our CI. There was some bad news, but I don't
> think it needs to block these patches.
>
> The good news was that I found that OpenGL testing with our iris
> driver appeared to have ok results when using this interface.
>
> But, our Vulkan Anvil driver was not stable with the current patches
> in the Mesa MR. We will need to debug this further before using the
> interface on Vulkan.
>
> I don't suspect that this is an issue with the kernel interface, so
> you can add:
>
> Tested-by: Jordan Justen <jordan.l.justen@intel.com>
I had a browse through the Mesa merge request and it looks all r-b-ed to
me. To confirm - it will get merged when we merge the i915 half?
Could you also give an a-b for the i915 patch please?
Regards,
Tvrtko
next prev parent reply other threads:[~2023-05-15 10:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 16:59 [Intel-gfx] [PATCH v7 0/4] drm/i915: Allow user to set cache at BO creation fei.yang
2023-05-09 16:59 ` fei.yang
2023-05-09 16:59 ` [Intel-gfx] [PATCH v7 1/4] drm/i915: preparation for using PAT index fei.yang
2023-05-09 16:59 ` fei.yang
2023-05-09 16:59 ` [Intel-gfx] [PATCH v7 2/4] drm/i915: use pat_index instead of cache_level fei.yang
2023-05-09 16:59 ` fei.yang
2023-05-09 16:59 ` [Intel-gfx] [PATCH v7 3/4] drm/i915/mtl: end support for set caching ioctl fei.yang
2023-05-09 16:59 ` fei.yang
2023-05-09 16:59 ` [Intel-gfx] [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation fei.yang
2023-05-09 16:59 ` fei.yang
2023-05-10 22:14 ` [Intel-gfx] " Andi Shyti
2023-05-10 22:14 ` Andi Shyti
2023-05-12 19:54 ` [Intel-gfx] " Jordan Justen
2023-05-12 19:54 ` Jordan Justen
2023-05-12 23:34 ` [Intel-gfx] " Yang, Fei
2023-05-12 23:34 ` Yang, Fei
2023-05-15 10:20 ` Tvrtko Ursulin [this message]
2023-05-15 10:20 ` Tvrtko Ursulin
2023-05-09 18:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Allow user to set cache at BO creation (rev7) Patchwork
2023-05-09 18:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-05-09 20:29 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=6ebba088-68e3-3f6e-4ccc-f29ab5d66fa9@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=adrinael@adrinael.net \
--cc=andi.shyti@linux.intel.com \
--cc=arek@hiler.eu \
--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=jordan.l.justen@intel.com \
--cc=matthew.d.roper@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.