e the batches submitted in parallel are nearly identical and
expected to run the same amount of time, right? Do we have any
userspace (or potential future userspace) that might submit
heterogeneous batches in parallel, which would make this inaccurate?
I'm not very familiar with the use cases of par
nd the first.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> Acked-by: Michal Mrozek
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c |
On Tue, Mar 26, 2024 at 07:42:34PM +0100, Andi Shyti wrote:
> Hi Matt,
>
> On Tue, Mar 26, 2024 at 09:03:10AM -0700, Matt Roper wrote:
> > On Wed, Mar 13, 2024 at 09:19:50PM +0100, Andi Shyti wrote:
> > > + /*
> > > + * Do not cr
irst
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
Reviewed-
nd the first.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 20
On Tue, Mar 12, 2024 at 04:43:06PM -0700, John Harrison wrote:
> On 3/12/2024 09:24, Matt Roper wrote:
> > On Thu, Mar 07, 2024 at 06:01:29PM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > An existing workaround has been
ryushin
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +++---
> drivers/gpu/drm/i915/intel_clock_gating.c | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/driv
n12_fw_ranges[] = {
> 0x1f6e00 - 0x1f7fff: reserved */
> \
> GEN_FW_RANGE(0x1f8000, 0x1fa0ff, FORCEWAKE_MEDIA_VEBOX3),
>
> -static const struct intel_forcewake_range __xehp_fw_ranges[] = {
> - XEHP_FWRANGES(FORCEWAKE_GT)
> -};
> -
>
load-balancing disable hasn't landed in i915 yet (although it
probably will soon). Assuming we wait for that to happen first before
applying this,
Reviewed-by: Matt Roper
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
> drivers/gpu/drm/i915/gt/uc/
_UABI_CLASS)
> + if (uabi_class > I915_LAST_UABI_ENGINE_CLASS)
> continue;
>
> + GEM_BUG_ON(uabi_class >=
> +ARRAY_SIZE(i915->engine_uabi_class_count));
> + i915->engine_uabi_class_count[uabi_class]++;
> +
> rb_link_node(>uabi_node, prev, p);
> rb_insert_color(>uabi_node, >uabi_engines);
>
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
t;)
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 23 +++--
> 2 files changed, 22 insertions(
> + guc_waklv_enable_simple(guc, , ,
> + GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE);
> + guc_waklv_enable_simple(guc, , ,
> +
> GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE);
> }
>
> size = guc_ads_waklv_size(guc) - remain;
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
irst
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Requires: 97aba5e46038 ("drm/i915/gt: Refactor uabi engine class/instance
> list creation")
> Signed-off-by: Andi Shyti
t;)
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
> 2 files changed, 6 insertions(+)
>
>
ction.
> + */
> + if (!(engine->gt->info.engine_mask &
> + BIT(_CCS(engine->uabi_instance
> + continue;
> +
> GEM_BUG_ON(uabi_class >=
> ARRAY_SIZE(i915-&g
On Thu, Feb 22, 2024 at 11:03:27PM +0100, Andi Shyti wrote:
> Hi Matt,
>
> first of all thanks a lot for the observations you are raising.
>
> On Wed, Feb 21, 2024 at 12:51:04PM -0800, Matt Roper wrote:
> > On Wed, Feb 21, 2024 at 01:12:18AM +0100, Andi Shyti wrote:
>
On Wed, Feb 21, 2024 at 01:12:18AM +0100, Andi Shyti wrote:
> Hi Matt,
>
> thanks a lot for looking into this.
>
> On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> > On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
>
> [...]
>
> > &g
irst
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/
t;)
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> 2 files changed, 7 insertions(+)
>
>
series.
Matt
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_
Assuming you can reword that,
Reviewed-by: Matt Roper
> should not try to create a fake PVC device since they can't find
> the right PCI ID. Fix bugs when running kunit:
>
> # xe_wa_gt: ASSERTION FAILED at
> drivers/gpu/drm/xe/tests/xe_wa_test.c:111
> Expe
On Thu, Jan 18, 2024 at 05:21:23PM -0800, Belgaumkar, Vinay wrote:
>
> On 1/18/2024 3:50 PM, Matt Roper wrote:
> > On Thu, Jan 18, 2024 at 03:17:28PM -0800, Vinay Belgaumkar wrote:
> > > Instead of waiting until the interrupt reaches GuC, we can grab a
> > > forc
NGE(0x3, 0x3, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x4, 0x1901ec, 0),
> + GEN_FW_RANGE(0x1901f0, 0x1901f0, FORCEWAKE_GT)
> + /* FIXME: WA to wake GT while triggering H2G */
> };
>
> /*
> --
> 2.38.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
On Tue, Jan 16, 2024 at 09:40:50AM -0800, Lucas De Marchi wrote:
> Now that all the issues with 32bits are fixed, enable it again.
>
> Signed-off-by: Lucas De Marchi
I didn't test locally, but assuming you confirmed all the warnings are
gone now,
Reviewed-by: Matt Roper
> ---
&g
f-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/xe/xe_trace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_trace.h b/drivers/gpu/drm/xe/xe_trace.h
> index 95163c303f3e..e4e7262191ad 100644
> --- a/drivers/gpu
s the Xe
compat header has an XE_WARN_ON that complains if any other size is
requested, but in theory this function is supposed to be general purpose
and take any size.
Matt
> else
> - *ptr = *(u64 *)(virtual + ofs);
> + iosys_map_set_vaddr(, virtual);
>
her variable in these function. Simply cast it to u64 and keep using
> %llx.
>
> Fixes: 286089ce6929 ("drm/xe: Improve vram info debug printing")
> Cc: Oak Zeng
> Cc: Michael J. Ruhl
> Cc: Matthew Brost
> Cc: Rodrigo Vivi
> Signed-off-by: Lucas De Marchi
Reviewe
On Tue, Jan 16, 2024 at 09:40:46AM -0800, Lucas De Marchi wrote:
> Use DIV_ROUND_UP_ULL() so it also works on 32bit build.
>
> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
>
ead?
The workaround is also listed in the database as applying to DG2; is
this "case 2" subset of the workaround not relevant to that platform?
Matt
> (ce->engine->class == COMPUTE_CLASS || ce->engine->class ==
> RENDER_CLASS)) {
> rcu_
gt; Cc: Ville Syrjälä
> Cc: # v6.2+
> Suggested-by: Matt Roper
> Signed-off-by: Nirmoy Das
> Acked-by: Andi Shyti
Reviewed-by: Matt Roper
Interestingly, bspec 151 indicates that we probably shouldn't have been
using a CPU:WC mapping for the GGTT on gen9bc platforms either (i.e.,
t
> > > > > >
> > > > > > > On the driver side we still have spinlocks that make sure that
> > > > > > > the access to the resources is serialized.
> > > > > > >
> > > > > > > Signed-off-by: Andi Shyti
>
> > > > >
> > > > > Do not consider this failure as an error, but just print a debug
> > > > > message stating that the MCR locking has been skipped.
> > > > >
> > > > > On the driver side we still have spinlocks that make sure t
.
> > v3: s/"MEDIA_VER(i915) == 13"/"MEDIA_VER(i915) >= 13"(Matt)
> > improve comment.
> > v4: improve the comment further(Andi)
> >
> > Signed-off-by: Nirmoy Das
> > Reviewed-by: Matt Roper
> > Reviewed-by: Andi Shyti
_gt_mcr_lock_clear/intel_gt_mcr_lock_sanitize
>
> Signed-off-by: Nirmoy Das
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 22 ++
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 1 +
> 2 files changed, 23 insertions(+)
>
/resume, as there
> + * are no lock acquisitions during this process by other
> + * agents.
> + */
> + if (MEDIA_VER(gt->i915) >= 13 && gt->type == GT_MEDIA)
> + intel_gt_mcr_lock_reset(gt);
> +
> intel_uncore_resume_early(gt->uncore);
> intel_gt_check_and_clear_faults(gt);
> }
> --
> 2.41.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
vers/gpu/drm/i915/gt/intel_gt_mcr.h
> @@ -11,6 +11,7 @@
> void intel_gt_mcr_init(struct intel_gt *gt);
> void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags);
> void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags);
> +void intel_gt_mcr_lock_reset(struct intel_gt *gt);
>
> u32 intel_gt_mcr_read(struct intel_gt *gt,
> i915_mcr_reg_t reg,
> --
> 2.41.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
ary GT. Is there some other workaround
(with a different lineage number) that asks us to do the same thing on
the primary GT?
Matt
>
> Signed-off-by: Nirmoy Das
> Signed-off-by: Andi Shyti
> Cc: Jonathan Cavitt
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel
d of "==" under the assumption future media versions will
do the same in case we get some kind of refresh platform down the road
with a slightly higher version number.
Aside from those minor tweaks,
Reviewed-by: Matt Roper
> + intel_unco
i
> Cc: # v5.8+
> Cc: Andrzej Hajda
> Cc: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Tejas Upadhyay
> Cc: Lucas De Marchi
> Cc: Prathap Kumar Valsan
> Cc: Tapani Pälli
> Cc: Mark Janes
> Cc: Rodrigo Vivi
> Signed-off-by: Nirmoy Das
Acked-by: Mat
> XELPMP_RING_FAULT_REG);
> +
> + else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
> ee->fault_reg = intel_gt_mcr_read_any(engine->gt,
>
> XEHP_RING_FAULT_REG);
> else if (GRAPHICS_VER(i915) >= 12)
> --
> 2.41.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
de flushing all the necessary bits? What about
PIPE_CONTROL_CCS_FLUSH?
Matt
>
> Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before
> invalidation")
> Cc: Jonathan Cavitt
> Cc: Andi Shyti
> Cc: # v5.8+
> Cc: Andrzej Hajda
> Cc: Tvrtko Ursulin
>
On Fri, Jul 28, 2023 at 01:39:06PM +0100, Tvrtko Ursulin wrote:
>
> Forgot one part of your reply:
>
> On 28/07/2023 00:57, Matt Roper wrote:
> > On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > >
On Fri, Jul 28, 2023 at 09:18:36AM +0100, Tvrtko Ursulin wrote:
>
> On 27/07/2023 23:25, Matt Roper wrote:
> > On Thu, Jul 27, 2023 at 03:54:58PM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > No need to run extra instruction
On Thu, Jul 27, 2023 at 04:57:53PM -0700, Matt Roper wrote:
> On Thu, Jul 27, 2023 at 03:55:00PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
> > introduced PAT ind
ject cache
> mode check.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Fei Yang
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ex
e_needs_clflush().
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Fei Yang
> Cc: Matt Roper
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_
rm.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Fei Yang
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/dri
size. (Matt)
> * Boolean cache mode and flags query. (Matt)
> * Reduce number of cache macros with some macro magic.
> * One more checkpatch fix.
> * Tweak tables to show legacy and Gen12 WB is fully coherent.
>
> Signed-off-by: Tvrtko Ursulin
> References: 9275277d5324 ("
function every time.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Fei Yang
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +--
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 7 ++---
> dr
HICS_VER(gt->i915) >= 12)
> ppgtt->vm.pte_encode = gen12_pte_encode;
I think you wanted 'else if' here. Otherwise you clobber the MTL
function pointer.
Matt
> else
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
buffer to a non-coherent domain.
>
> Use the opportunity to documet the situation on discrete too.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Fei Yang
> Cc: Matthew Auld
> Cc: Thomas Hellström
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/
e for all
> engines")
> Signed-off-by: Andi Shyti
> Cc: Jonathan Cavitt
> Cc: Nirmoy Das
> Cc: # v5.8+
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
> 2 files ch
ing a
> boolean gen12_needs_ccs_aux_inv() function that tells whether aux
> invalidation is needed or not.
>
> Currently PVC is the only exception to the above mentioned rule.
>
> Signed-off-by: Andi Shyti
> Cc: Matt Roper
> Cc: Jonathan Cavitt
> Cc: # v5.8+
Reviewed
_GTT_RELOC)
> >>>>> return false;
> >>>>>
> >>>>> -/*
> >>>>> - * For objects created by userspace through GEM_CREATE with
> >>>>> pat_index
> >>>>> - * set by set_pat extension, i915_gem_object_has_cache_level()
> >>>>> always
> >>>>> - * return true, otherwise the call would fall back to checking
> >>>>> whether
> >>>>> - * the object is un-cached.
> >>>>> - */
> >>>>> return (cache->has_llc ||
> >>>>> obj->cache_dirty ||
> >>>>> -!i915_gem_object_has_cache_level(obj, I915_CACHE_NONE));
> >>>>> +i915_gem_object_has_cache_mode(obj,
> >>>>> + I915_CACHE_MODE_UC) != 1);
> >>>>
> >>>> Platforms with relocations and platforms with user-specified PAT
> >>>> have no overlap, right? So a -1 return should be impossible here
> >>>> and this is one case where we could just treat the return value as
> >>>> a boolean, right?
> >>>
> >
> > Hm no, or maybe. My thinking behind tri-state is to allow a safe option
> > for "don't know". In case PAT index to cache mode table is not fully
> > populated on some future platform.
>
> That would be a problem in the cache mode table. At least max_pat_index
> should have guaranteed the PAT index is sane.
>
> -Fei
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
/i915/gt/intel_gpu_commands.h
> @@ -299,6 +299,7 @@
> #define PIPE_CONTROL_QW_WRITE (1<<14)
> #define PIPE_CONTROL_POST_SYNC_OP_MASK(3<<14)
> #define PIPE_CONTROL_DEPTH_STALL (1<<13)
> +#define PIPE_C
urn PTR_ERR(cs);
> -
> - cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1,
> - LRC_PPHWSP_SCRATCH_ADDR);
> - intel_ring_advance(rq, cs);
> + intel_emit_pipe_control_cs(rq, bit_group_0, bit_group_1,
> +LRC_PPHWSP_SCRATCH_ADDR);
> }
>
> if (mode & EMIT_INVALIDATE) {
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
want to stick with the flag it's
probably best to rename it slightly so that it more accurately reflects
what we're using it for.
Matt
>
> Signed-off-by: Andi Shyti
> Cc: Matt Roper
> Cc: Jonathan Cavitt
> Cc: # v5.8+
> ---
> drivers/gpu/drm/i915/gt/gen8_engine
f being removed.
These lines got replaced with a check for the specific PAT indices that
are problematic rather than just assuming any user-provided PAT might
cause problems. But I had some concerns about the specific logic there
in my review as well.
Matt
>
> >> /*
> >> * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
> >> * possible for userspace to bypass the GTT caching bits set by the
> >> @@ -226,7 +242,21 @@ bool i915_gem_object_can_bypass_llc(struct
> >> drm_i915_gem_object *obj)
> >> * it, but since i915 takes the stance of always zeroing memory before
> >> * handing it to userspace, we need to prevent this.
> >> */
> >> -return IS_JSL_EHL(i915);
> >> +if (IS_JSL_EHL(i915))
> >> +return true;
> >> +
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
ss_llc() (Matt)
>
> v3:
> * Checkpath issues.
> * Cache mode flags check fixed.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Cc: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
>
> But isn't it the same the patch you linked is doing?
>
> return !xe->info.has_flat_ccs;
No, that's just the end of the function. The important
platform-specific checks come before that point (at the moment we only
have PVC, but we expect more platforms to be added there very soon too).
Matt
>
> And
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
On Mon, Jul 17, 2023 at 11:52:25PM +0200, Andi Shyti wrote:
> Hi Matt,
>
> On Mon, Jul 17, 2023 at 01:31:03PM -0700, Matt Roper wrote:
> > On Mon, Jul 17, 2023 at 10:54:37AM -0700, Matt Roper wrote:
> > > On Mon, Jul 17, 2023 at 07:30:55PM +0200, Andi Shyti wrote:
>
On Mon, Jul 17, 2023 at 10:54:37AM -0700, Matt Roper wrote:
> On Mon, Jul 17, 2023 at 07:30:55PM +0200, Andi Shyti wrote:
> > From: Jonathan Cavitt
> >
> > All memory traffic must be quiesced before requesting
> > an aux invalidation on platforms that use Aux CCS.
&
6014892111 */
> if (IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) ||
> @@ -1399,17 +1396,7 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
> *ce, u32 *cs)
>
> PIPE_CONTROL_INSTRUCTION_CACHE_INVA
arlier patch, we should probably make this check that
the platform actually has AuxCCS.
Anyway, up to you whether you want to make that change or not. The
extra noops don't actually hurt anything.
Reviewed-by: Matt Roper
> - count = 8 + 4;
> - else
> -
ssion on pre-gen8 platforms.
Anyway, adding the extra condition shouldn't really hurt anything
either, so up to you whether you want to drop it or not.
Reviewed-by: Matt Roper
>
> if (mode & EMIT_FLUSH) {
> u32 bit_group_0 = 0;
> @@ -221,6 +221,14 @@ int g
On Mon, Jul 17, 2023 at 07:30:56PM +0200, Andi Shyti wrote:
> In preparation of the next patch allign with the datasheet (BSPEC
s/allign/align/
Otherwise,
Reviewed-by: Matt Roper
> 47112) with the naming of the pipe control set of flag values.
> The variable "flags" in g
op.org/patch/539304/?series=118334=1
Matt
> + mode |= EMIT_FLUSH;
> +
> if (mode & EMIT_FLUSH) {
> u32 flags = 0;
> int err;
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
en we probably should apply the blanket IS_METEORLAKE condition.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> > > Cc: Chris Wilson
> > > Cc: Fei Yang
> > > Cc: An
that, move the programming of
> GEN12_FF_MODE2 to a single place so the value passed for "clear" can
> be all the bits. Otherwise the second workaround would be dropped as
> it'd be detected as overwriting a previously programmed workaround.
>
> Signed-off-by: Lucas De Mar
mming of L3SQCREG5 in dg2_ctx_gt_tuning_init(). With
> > > >> the GPU idle, that register could be read via intel_reg as 0x00e001ff,
> > > >> but during a 3D workload it would change to 0x007f. So the
> > > >> programming of that tuning was affecting more than the bits in
> > &
On Thu, Jun 15, 2023 at 04:04:18PM +0300, Oded Gabbay wrote:
> On Thu, Jun 15, 2023 at 3:01 AM Matt Roper wrote:
> >
> > On Mon, Jun 12, 2023 at 06:31:57PM +0200, Francois Dugast wrote:
> > > On Thu, Jun 08, 2023 at 10:35:29AM -0700, Lucas De Marchi wrote:
> > >
cache_coherent and obj->cache_dirty are still
>there for objects created by kernel.
Right, that's the challenge --- userspace is taking over control of this
stuff, but the fields are still around and still used internally within
the driver. How we reconcile those two things needs to be cle
en12_pte_encode and
> apply it to all gen12 platforms.
>
> Cc: Chris Wilson
> Cc: Matt Roper
> Signed-off-by: Fei Yang
> Reviewed-by: Andi Shyti
Bspec: 63019
Reviewed-by: Matt Roper
I think it's important to include the bspec reference here since we have
so much trouble finding pr
me explanation of
how that works in the commit message (and likely in the kerneldoc for
that field too).
>
> Cc: Chris Wilson
> Cc: Matt Roper
> Signed-off-by: Fei Yang
> Reviewed-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 12 +--
&
because we don't have platform info here.
> Or we would have to define another PTE encode function for platforms
> needing PTE_NC just for this one difference, then manage the function
> pointer correctly.
MTL is the only platform that uses this function right now:
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
If this is intended for PVC, then you have it in the wrong function to
begin with (and it also shouldn't be in a patch labelled "mtl"). If
you're trying to future-proof for some post-MTL discrete platform, then
such code should be saved until we enable that platform so that it can
be properly reviewed.
Matt
>
> -Fei
>
> > Matt
> >
> >> -Fei
> >>> Matt
> >>>
> >>>> +
> >>>> + switch (level) {
> >>>> + case I915_CACHE_NONE:
> >>>> + pte |= GEN12_PPGTT_PTE_PAT1;
> >>>> + break;
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
or 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
>
On Fri, Apr 21, 2023 at 10:37:55AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> Media GT has a different base for MOCS register, need to apply
> gsi_offset to the mmio address if not using the intel_uncore_r/w
> functions for register access.
>
> Cc: Matt Roper
IT(5). But
>> according to bspec 45040, bit 5 is ignored in the PTE encoding. What is
>> this trying to do?
>This takes effect only for PTE_LM, doesn't affect MTL.
>PTE_NC is needed for PVC (use of access counter).
>I believe this function was writen based on the one for PVC. And this
>function
>did get extended to cover all gen12 in a later patch.
Even though MTL doesn't have local memory, PTE_LM is supposed to be used
on MTL for access to BAR2 stolen memory.
Matt
>-Fei
>> Matt
>>
>>> +
>>> + switch (level) {
>>> + case I915_CACHE_NONE:
>>> + pte |= GEN12_PPGTT_PTE_PAT1;
>>> + break;
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
4..99a0a89091e7 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -902,6 +902,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
> ct_incoming_msg **msg)
> /* now update descriptor */
> WRITE_ONCE(desc->head, head);
>
> + /*
> + * Wa_22016122933: Making sure the head update is
> + * visible to GuC right away
> + */
> + intel_guc_write_barrier(ct_to_guc(ct));
> +
> return available - len;
>
> corrupted:
> --
> 2.39.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
e PAT index registers are multicasted for primary GT,
> and there is an address jump from index 7 to 8. This patch
> makes sure that these registers are programmed in the proper
> way.
>
> BSpec: 44509, 45101, 44235
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: M
ache_level for the
> convenience of coding.
>
> Cc: Chris Wilson
> Cc: Matt Roper
> Cc: Andi Shyti
> Signed-off-by: Fei Yang
> Reviewed-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 9 +++
> drivers/gpu/drm/i915/gem
gt;= IP_VER(12, 70)))
> /* On some devices, we can have the GPU use the LLC (the CPU
>* cache) for about a 10% performance improvement
>* compared to uncached. Graphics requests other than
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
tion that translates to at the x86 level.
Aside from simplifying the commit message,
Reviewed-by: Matt Roper
>
> While fixing the CTB issue, we noticed some random GSC firmware
> loading failure because the share buffers are cacheable (WB) on CPU
> side but uncached on GPU side. To
vel,
>u32 flags)
> {
> - const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, flags);
> struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> + const gen8_pte_t pte_encode = ggtt->vm.pte_encode(0, level, flags);
> gen8_pte_t __iomem *gte;
> gen8_pte_t __iomem *end;
> struct sgt_iter iter;
> @@ -981,7 +1008,10 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
> ggtt->vm.vma_ops.bind_vma= intel_ggtt_bind_vma;
> ggtt->vm.vma_ops.unbind_vma = intel_ggtt_unbind_vma;
>
> - ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> + ggtt->vm.pte_encode = mtl_ggtt_pte_encode;
> + else
> + ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>
> return ggtt_probe_common(ggtt, size);
> }
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
e PAT index registers are multicasted for primary GT,
> and there is an address jump from index 7 to 8. This patch
> makes sure that these registers are programmed in the proper
> way.
>
> BSpec: 44509, 45101, 44235
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
>
ich GT you grab an uncore from, and display/gunit isn't
something that PVC even needs to worry about. So
Reviewed-by: Matt Roper
> v2 -> v3
> - keep GUnit irq initialization out of the for_each_gt() loop as
>the media GT doesn't have a GUnit.
> v1 -> v2
> - improve
On Thu, Apr 13, 2023 at 06:19:16PM +0200, Andi Shyti wrote:
> On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote:
> >
> >
> > On 4/13/2023 8:52 AM, Matt Roper wrote:
> > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote:
> >
On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote:
>
>
> On 4/13/2023 8:52 AM, Matt Roper wrote:
> > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote:
> > > Hi Tvrtko,
> > >
> > > (I forgot to CC Daniele)
> > &
to restart the
> discussion as this patch was just dropped.
>
> Thanks,
> Andi
>
>
> (*)
> [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7)
> [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT)
> status=0X0
> [drm] *ERROR*
AT_L4_CACHE_POLICY_MASK, 1)
>
>>> +#define MTL_PPAT_L4_0_WB
>REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
>
>>> +#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>3)
>
>>> +#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK,
>2)
>
>>> +#define MTL_0_COH_NON REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 0)
>
>>
>
>>The values for these definitions don't seem to be aligned.
>
>
>
>These are aligned with
>[10]https://gfxspecs.intel.com/Predator/Home/Index/45101
I mean spacing aligned. If your tabstops are set to 8, then the values
don't line up visually.
Matt
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
> MTL as it has different PAT index definition than previous
> platforms.
It might be best to keep the PTE encoding as a separate patch from the
MOCS/PAT tables. It's a different enough topic that it probably
deserves a patch of its own.
>
> BSpec: 44509, 45101, 44235
>
> Cc:
On Wed, Apr 05, 2023 at 02:13:31PM -0700, John Harrison wrote:
> On 4/3/2023 17:34, Matt Roper wrote:
> > On Mon, Apr 03, 2023 at 02:33:34PM -0700, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > A pair of pre-Gen12 registers were
s don't use GuC submission unless you force it with the
enable_guc modparam and taint your kernel), but I figured I should point
it out.
Reviewed-by: Matt Roper
[1] Why is the main list we use called xe_lpd (i.e., the name of ADL-P's
display IP)? It doesn't seem like we're doing anything with displa
the source of memory access
characteristics for anything that can't provide a MOCS directly.
Matt
>
> > 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 Fri, Mar 31, 2023 at 07:22:06AM -0600, Lucas De Marchi wrote:
> On Mon, Mar 27, 2023 at 10:02:38AM -0700, Matt Roper wrote:
> > On Thu, Mar 23, 2023 at 10:17:53PM -0700, Lucas De Marchi wrote:
> > > Platform order is important when looping through the list of guc
> > &
; fw_def(ALDERLAKE_S, guc_def(tgl, 70, 5, 2)) \
> - fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
> fw_def(DG2, guc_def(dg2, 70, 5, 2)) \
> fw_def(DG1, guc_def(dg1, 70, 5, 2)) \
> fw_def(TIGERLAKE,guc_def(tgl, 70, 5, 2))
> --
> 2.39.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
m. This can be reintroduced later if ever needed.
I doubt we'd ever need the revid again; more likely we'd want a way to
select different firmwares for a given subplatform (which is something I
think we need to add anyway for ADL-N).
Reviewed-by: Matt Roper
Matt
>
> With the removal o
t; + dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
> + intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
> }
>
> static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
On Tue, Mar 21, 2023 at 06:09:35PM +0100, Andi Shyti wrote:
> From: Matt Roper
>
> We occasionally see the PCI device in a non-accessible state at the
> point the driver is loaded. When this happens, all BAR accesses will
> read back as 0x. Rather than re
o emulate the behavior of the timeline
> >> anyway.
> >>
> >> Signed-off-by: Fei Yang
> >
> > It looks like there might be an indentation mistake on the second line
> > of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
> > w
1 - 100 of 1193 matches
Mail list logo
