RE: [RFC 4/8] drm/i915: Refactor PAT/object cache handling

[snip] > @@ -41,14 +42,17 @@ static bool gpu_write_needs_clflush(struct > drm_i915_gem_object *obj) > return false; > > /* > - * For objects created by userspace through GEM_CREATE with pat_index > - * set by set_pat extension, i915_gem_object_has_cache_level() will

RE: [RFC 1/8] drm/i915: Skip clflush after GPU writes on Meteorlake

> From: Tvrtko Ursulin > > On Meteorlake CPU cache will not contain stale data after GPU > access since write-invalidate protocol is used, which means > there is no need to flush before potentially transitioning the > buffer to a non-coherent domain. > > Use the opportunity to documet the

RE: [PATCH v3] drm/i915: Refactor PAT/object cache handling

>>> [snip] > @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct > drm_i915_gem_object *obj) The code change here looks accurate, but while we're here, I have a side question about this function in general...it was originally introduced in commit 48004881f693

RE: [PATCH v3] drm/i915: Refactor PAT/object cache handling

[snip] >> @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct >> drm_i915_gem_object *obj) > > The code change here looks accurate, but while we're here, I have a side > question about this function in general...it was originally introduced > in commit 48004881f693 ("drm/i915: Mark CPU

RE: [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc

> On 14/07/2023 06:43, Yang, Fei wrote: >>> From: Tvrtko Ursulin >>> >>> According to the comment in i915_gem_object_can_bypass_llc the >>> purpose of the function is to return false if the platform/object has >>> a caching mode where GPU can b

RE: [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc

> From: Tvrtko Ursulin > > According to the comment in i915_gem_object_can_bypass_llc the > purpose of the function is to return false if the platform/object > has a caching mode where GPU can bypass the LLC. > > So far the only platforms which allegedly can do this are Jasperlake > and

RE: [RFC 1/2] drm/i915: Refactor PAT/object cache handling

[snip] > @@ -326,10 +330,10 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, > void *data, > goto out; > } > > - if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) || > - i915_gem_object_has_cache_level(obj, I915_CACHE_L3_LLC)) > + if

RE: [PATCH] drm/i915: Remove dead code from gen8_pte_encode

> From: Tvrtko Ursulin > > Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") > added a dedicated gen12_pte_encode but forgot to remove the Gen12 > specific bit from gen8_pte_encode. Reviewed-by: Fei Yang > Signed-off-by: Tvrtko Ursulin > Fixes: 9275277d5324 ("drm/i915:

Re: [PATCH v2] drm/i915: Refactor PAT/cache handling

> @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct > drm_i915_gem_object *obj) > if (IS_DGFX(i915)) > return false; > - /* > -* For objects created by userspace through GEM_CREATE with > pat_index > -* set

Re: [PATCH] drm/i915/mtl: Update cache coherency setting for context structure

> As context structure is shared memory for CPU/GPU, Wa_22016122933 is > needed for this memory block as well. > > Signed-off-by: Zhanjun Dong > CC: Fei Yang Reviewed-by: Fei Yang > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >

Re: [PATCH v2] drm/i915: Refactor PAT/cache handling

>>> From: Tvrtko Ursulin >>> >>> Informal commit message for now. >>> >>> I got a bit impatient and curious to see if the idea we discussed would >>> work so sketched something out. I think it is what I was describing back >>> then.. >>> >>> So high level idea is to teach the driver what caching

Re: [PATCH v8 1/2] drm/i915: preparation for using PAT index

> On 27/06/2023 14:28, Jani Nikula wrote: >> On Tue, 09 May 2023, fei.y...@intel.com wrote: >>> From: Fei Yang >>> >>> This patch is a preparation for replacing enum i915_cache_level with >>> PAT index. Caching policy for buffer objects is set through the PAT >>> index in PTE, the old

Re: [PATCH v8 1/2] drm/i915: preparation for using PAT index

> Hi Jani and Tvrtko, > This patch is a preparation for replacing enum i915_cache_level with PAT index. Caching policy for buffer objects is set through the PAT index in PTE, the old i915_cache_level is not sufficient to represent all caching modes supported by the hardware.

Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove incorrect hard coded cache coherrency setting

> The previouse i915_gem_object_create_internal already set it with proper > value before function return. This hard coded setting is incorrect for > platforms like MTL, thus need to be removed. > > Signed-off-by: Zhanjun Dong > --- > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 -- > 1 file

Re: [PATCH v17 1/1] drm/i915: Allow user to set cache at BO creation

> Hi Carl, > besides this, ask a dumb question. How we retrieve the pat_index from a shared resource though dma_buf fd? maybe we need to know whether it could be CPU cached if we want map it. Of course, looks there are no real usage to access it though CPU. Just use it

Re: [Intel-gfx] [PATCH v15 1/1] drm/i915: Allow user to set cache at BO creation

>> On 31/05/2023 18:10, fei.y...@intel.com wrote: >>> From: Fei Yang >>> >>> 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 >>>

Re: [Intel-gfx] [PATCH v15 1/1] drm/i915: Allow user to set cache at BO creation

> On 31/05/2023 18:10, fei.y...@intel.com wrote: >> From: Fei Yang >> >> 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

Re: [Intel-gfx] [PATCH v15 0/1] drm/i915: Allow user to set cache at BO creation

> On 05/06/2023 09:53, Tvrtko Ursulin wrote: >> On 31/05/2023 18:10, fei.y...@intel.com wrote: >>> From: Fei Yang >>> >>> This series introduce a new extension for GEM_CREATE, >>> 1. end support for set caching ioctl [PATCH 1/2] >>> 2. add set_pat extension for gem_create [PATCH 2/2] >>> >>> v2:

Re: [PATCH v15 1/1] drm/i915: Allow user to set cache at BO creation

> Hi Fei, > > On Wed, May 31, 2023 at 10:10:08AM -0700, fei.y...@intel.com wrote: >> From: Fei Yang >> >> 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

RE: [PATCH 2/2] drm/i915/gt: Fix parameter in gmch_ggtt_insert_{entries,page}()

> Subject: [PATCH 2/2] drm/i915/gt: Fix parameter in > gmch_ggtt_insert_{entries,page}() > > When building with clang's -Wincompatible-function-pointer-types-strict, > the following warnings occur: > > drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c:102:23: error: incompatible > function pointer

RE: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8 pte_encode callbacks

> Subject: [PATCH 1/2] drm/i915/gt: Fix second parameter type of pre-gen8 > pte_encode callbacks > > When booting a kernel compiled with CONFIG_CFI_CLANG (kCFI), there is a CFI > failure in ggtt_probe_common() when trying to call hsw_pte_encode() via an > indirect call: > > [5.030027] CFI

RE: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

Sorry replied on top of wrong thread. From: Yang, Fei Sent: Thursday, May 25, 2023 8:12 AM To: Tvrtko Ursulin ; intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org; Vivi, Rodrigo Subject: Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation Sounds

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

> On 24/05/2023 21:02, fei.y...@intel.com wrote: >> From: Fei Yang >> >> This series introduce a new extension for GEM_CREATE, >> 1. end support for set caching ioctl [PATCH 1/2] >> 2. add set_pat extension for gem_create [PATCH 2/2] >> >> v2: drop one patch that was merged separately >>

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

Sounds weird to have a platform restriction on uAPI though. UMD not using this extension is not a problem, is it? From: Tvrtko Ursulin Sent: Thursday, May 25, 2023 1:33 AM To: Yang, Fei ; intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org ; Vivi, Rodrigo Subject: Re

Re: [Intel-gfx] [PATCH v9 2/2] drm/i915: Allow user to set cache at BO creation

> On 16/05/2023 19:11, fei.y...@intel.com wrote: >> From: Fei Yang >> >> 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

Re: [PATCH v8 2/2] drm/i915: Allow user to set cache at BO creation

> Hi Fei, > > On Fri, May 12, 2023 at 04:28:25PM -0700, fei.y...@intel.com wrote: >> From: Fei Yang >> >> 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

Re: [PATCH v7 4/4] drm/i915: Allow user to set cache at BO creation

> On 2023-05-10 15:14:16, Andi Shyti wrote: >> Hi, >> >> On Tue, May 09, 2023 at 09:59:42AM -0700, fei.y...@intel.com wrote: >>> From: Fei Yang >>> >>> To comply with the design that buffer objects shall have immutable >>> cache setting through out their life cycle, {set, get}_caching ioctl's >>>

Re: [PATCH v5 2/3] drm/i915: use pat_index instead of cache_level

> On Sun, May 07, 2023 at 11:39:18PM -0700, Yang, Fei wrote: >>> On Wed, May 03, 2023 at 03:50:59PM -0700, fei.y...@intel.com wrote: >>>> From: Fei Yang >>>> >>>> Currently the KMD is using enum i915_cache_level to set caching policy for >>

RE: [PATCH v5 2/5] drm/i915: use pat_index instead of cache_level

static u64 mtl_pte_encode(dma_addr_t addr, - enum i915_cache_level level, + unsigned int pat_index, u32 flags) >>> Prototype and implementation changed here for mtl_pte_encode. >>> >>> And we have: >>>

Re: [PATCH v5 2/5] drm/i915: use pat_index instead of cache_level

> On 04/05/2023 00:02, fei.y...@intel.com wrote: >> From: Fei Yang >> >> Currently the KMD is using enum i915_cache_level to set caching policy for >> buffer objects. This is flaky because the PAT index which really controls >> the caching behavior in PTE has far more levels than what's defined

RE: [Intel-gfx] [PATCH v4 2/3] drm/i915: use pat_index instead of cache_level

[...] >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> index 8c70a0ec7d2f..27c948350b5b 100644 >> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c >> @@ -54,6 +54,25 @@ unsigned int

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

> On 27/04/2023 17:07, Yang, Fei wrote: >>> On 26/04/2023 16:41, Yang, Fei wrote: >>>>> On 26/04/2023 07:24, fei.y...@intel.com wrote: >>>>>> From: Fei Yang >>>>>> >>>>>> The first three patches in

Re: [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation

>> On 4/28/23 17:19, Yang, Fei wrote: >>> On 4/28/23 07:47, fei.y...@intel.com wrote: >>>> From: Fei Yang >>>> >>>> The first three patches in this series are taken from >>>> https://patchwork.freedesktop.org/series/116868/ >&

Re: [PATCH v3 0/5] drm/i915: Allow user to set cache at BO creation

> On 4/28/23 07:47, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The first three patches in this series are taken from >> https://patchwork.freedesktop.org/series/116868/ >> These patches are included here because the last patch >> has dependency on the pat_index refactor. >> >> This series

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

> On 26/04/2023 16:41, Yang, Fei wrote: >>> On 26/04/2023 07:24, fei.y...@intel.com wrote: >>>> From: Fei Yang >>>> >>>> The first three patches in this series are taken from >>>> https://patchwork.freedesktop.org/series/116868/ >>

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

> On 26/04/2023 07:24, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The first three patches in this series are taken from >> https://patchwork.freedesktop.org/series/116868/ >> These patches are included here because the last patch >> has dependency on the pat_index refactor. >> >> This

Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function

> On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote: >>> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote: >>>>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote: >>>>>> From: Fei Yang >>>>>>

RE: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function

> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote: >>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote: >>>> From: Fei Yang >>>> >>>> PTE encode functions are platform dependent. This patch implements >>>&g

RE: [Intel-gfx] [PATCH 7/8] drm/i915: use pat_index instead of cache_level

> On 20/04/2023 00:00, fei.y...@intel.com wrote: >> From: Fei Yang >> >> Currently the KMD is using enum i915_cache_level to set caching policy for >> buffer objects. This is flaky because the PAT index which really controls >> the caching behavior in PTE has far more levels than what's defined

RE: [Intel-gfx] [PATCH 7/8] drm/i915: use pat_index instead of cache_level

> On 20/04/2023 00:00, fei.y...@intel.com wrote: >> From: Fei Yang >> >> Currently the KMD is using enum i915_cache_level to set caching policy >> for buffer objects. This is flaky because the PAT index which really >> controls the caching behavior in PTE has far more levels than what's >>

Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function

> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote: >> From: Fei Yang >> >> PTE encode functions are platform dependent. This patch implements >> PTE functions for MTL, and ensures the correct PTE encode function >> is used by calling pte_encode function pointer instead of the

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation

> On 20/04/2023 12:39, Andi Shyti wrote: >> Hi Fei, >> >>> 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

RE: [Intel-gfx] [PATCH 2/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

> Hi Fei, > >> +#define MTL_PPGTT_PTE_PAT3 BIT_ULL(62) >> #define GEN12_PPGTT_PTE_LM BIT_ULL(11) >> +#define GEN12_PPGTT_PTE_PAT2BIT_ULL(7) >> +#define GEN12_PPGTT_PTE_NC BIT_ULL(5) >> +#define GEN12_PPGTT_PTE_PAT1BIT_ULL(4) >> +#define GEN12_PPGTT_PTE_PAT0BIT_ULL(3) >>

RE: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Set has_llc=0

> Hi Fei, > > On Wed, Apr 19, 2023 at 02:12:12PM -0700, fei.y...@intel.com wrote: >> From: Fei Yang >> >> On MTL, LLC is not shared between GT and CPU, set has_llc=0. >> >> Signed-off-by: Fei Yang > > just an unanswered questino from Nirmoy: > > This statement is bit unclear to me. I would say

RE: [Intel-gfx] [PATCH 4/8] drm/i915/mtl: workaround coherency issue for Media

>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >>> index 1803a633ed64..98e682b7df07 100644 >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >>> @@ -415,12 +415,6 @@ static int

RE: [Intel-gfx] [PATCH 5/8] drm/i915/mtl: end support for set caching ioctl

> On 17.04.2023 08:25, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The design is to keep Buffer Object's caching policy immutable through >> out its life cycle. This patch ends the support for set caching ioctl >> from MTL onward. While doing that we also set BO's to be 1-way >> coherent at

RE: [Intel-gfx] [PATCH 4/8] drm/i915/mtl: workaround coherency issue for Media

>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >> index 1803a633ed64..98e682b7df07 100644 >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c >> @@ -415,12 +415,6 @@ static int

RE: [Intel-gfx] [PATCH 2/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

>> On MTL, GT can no longer allocate on LLC - only the CPU can. >> This, along with addition of support for L4 cache calls a > s/calls a/calls for a Will update >> MOCS/PAT table update. >> Alos the PAT index registers are multicasted for primary GT, > s/Alos/Also >> and there is an address jump

RE: [Intel-gfx] [PATCH 2/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

>> void setup_private_pat(struct intel_gt *gt) >> >> GEM_BUG_ON(GRAPHICS_VER(i915) < 8); >> >> -if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) >> -xehp_setup_private_ppat(gt); >> -else if (GRAPHICS_VER(i915) >= 12) >> -tgl_setup_private_ppat(uncore); >> -

RE: [Intel-gfx] [PATCH 2/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

> Hi Fei, > > On Sun, Apr 16, 2023 at 11:24:57PM -0700, fei.y...@intel.com wrote: >> From: Madhumitha Tolakanahalli Pradeep >> >> >> On MTL, GT can no longer allocate on LLC - only the CPU can. >> This, along with addition of support for L4 cache calls a MOCS/PAT >> table update. >> Alos the PAT

RE: [Intel-gfx] [PATCH 0/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

> fei.y...@intel.com kirjoitti 17.4.2023 klo 9.24: >> From: Fei Yang >> >> The series includes patches needed to enable MTL. >> Also add new extension for GEM_CREATE uAPI to let user space set cache >> policy for buffer objects. > > if I'm counting right, this would be version 5 of the series,

RE: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO > creation > > On 2023-04-05 13:26:43, Jordan Justen wrote: >> On 2023-04-05 00:45:24, Lionel Landwerlin wrote: >>> On 04/04/2023 19:04, Yang, Fei wrote: >>>>> Subject: Re: [I

RE: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

> Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables > for MTL > > On Mon, Apr 10, 2023 at 08:55:16PM -0700, Yang, Fei wrote: > ... >>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h >> >>>> b/drivers/gpu/drm/i

RE: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables >for MTL > > On Fri, Apr 07, 2023 at 12:12:29AM -0700, > fei.y...@intel.com wrote: >> From: Fei Yang fei.y...@intel.com >> >> On MTL, GT can no longer allocate on

RE: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables for MTL

>Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables >for MTL > > Hi Fei, > > On Mon, Apr 03, 2023 at 03:50:26PM +0300, Jani Nikula wrote: >> On Fri, 31 Mar 2023, fei.y...@intel.com wrote: >>> From: Fei Yang >>> >>> On MTL, GT can no longer allocate on LLC - only the

Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables for MTL

> On 4/1/2023 8:38 AM, fei.y...@intel.com wrote: >> From: Fei Yang >> >> On MTL, GT can no longer allocate on LLC - only the CPU can. >> This, along with addition of support for ADM/L4 cache calls a >> MOCS/PAT table update. >> Also add PTE encode functions for MTL as it has different PAT >>

RE: [PATCH 5/7] drm/i915: use pat_index instead of cache_level

> On Mon, Apr 03, 2023 at 07:39:37PM +0000, Yang, Fei wrote: >>> Subject: Re: [PATCH 5/7] drm/i915: use pat_index instead of cache_level >>> >>> On Mon, Apr 03, 2023 at 04:57:21PM +, Yang, Fei wrote: >>>>> Subject: Re: [PATCH 5/7] drm/i91

RE: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

>Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO >creation > >On 04/04/2023 19:04, Yang, Fei wrote: >>> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set >>> cache at BO creation >>> >>> On 01/04/2023 09:3

RE: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO > creation > > On 01/04/2023 09:38, fei.y...@intel.com wrote: >> From: Fei Yang >> >> To comply with the design that buffer objects shall have immutable >> cache setting through out its life cycle, {set, get}_caching

RE: [PATCH 5/7] drm/i915: use pat_index instead of cache_level

>Subject: Re: [PATCH 5/7] drm/i915: use pat_index instead of cache_level > >On Mon, Apr 03, 2023 at 04:57:21PM +0000, Yang, Fei wrote: >>> Subject: Re: [PATCH 5/7] drm/i915: use pat_index instead of >>> cache_level >>> >>> On Fri, Mar 31, 2023

RE: [PATCH 5/7] drm/i915: use pat_index instead of cache_level

> Subject: Re: [PATCH 5/7] drm/i915: use pat_index instead of cache_level > > On Fri, Mar 31, 2023 at 11:38:28PM -0700, fei.y...@intel.com wrote: >> From: Fei Yang >> >> Currently the KMD is using enum i915_cache_level to set caching policy for >> buffer objects. This is flaky because the PAT

RE: [PATCH] drm/i915/selftests: keep same cache settings as timeline

>> From: Fei Yang >> >> On MTL, objects allocated through i915_gem_object_create_internal() are >> mapped as uncached in GPU by default because HAS_LLC is false. However >> in the live_hwsp_read selftest these watcher objects are mapped as WB >> on CPU side. The conseqence is that the updates

RE: [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

>> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c >> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c >> > @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt) >> >[VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR, >> >[VIDEO_ENHANCEMENT_CLASS] =

RE: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

>> +u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs) >> -static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs) > > I think all helpers which emit to ring take cs as the first argument so it > would be good to make this consistent. Updated the patch, please

RE: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

>> static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs) >> { >> *cs++ = MI_LOAD_REGISTER_IMM(1); >> @@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 >> mode) >> if (!HAS_FLAT_CCS(rq->engine->i915)) { >> aux_inv

RE: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

>> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c >> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c >> index 1c82caf525c3..0ec4986e4805 100644 >> --- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c >> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c >> @@ -37,6 +37,9 @@ int gen2_emit_flush(struct

RE: [PATCH] drm/i915: avoid concurrent writes to aux_inv

>>> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c >>> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c >>> index e1470bb60f34..7e8552414275 100644 >>> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c >>> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c

RE: [PATCH] drm/i915: avoid concurrent writes to aux_inv

>> @@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq, >> u32 mode) >> intel_ring_advance(rq, cs); >> } >> >> +/* hsdes: 1809175790. No fixup needed for gen11 rcs */ >> +rq->aux_inv_fixup = NULL; > > This is a little ugly to me. Can we just set this to

RE: [intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv (rev3)

Hi Chris, for some reason I didn't receive the review email, so I copied your comments from patchwork and faked this email. >> static void execlists_dequeue(struct intel_engine_cs *engine) >> { >> struct intel_engine_execlists * const execlists = >execlists; >> @@ -1538,6 +1566,16 @@