Re: [Intel-gfx] [PATCH v7 1/3] drm/i915: fix whitelist selftests with readonly registers
For the series:
Tested-by: Anuj Phogat
On Fri, Jun 28, 2019 at 5:07 AM Lionel Landwerlin
wrote:
>
> When a register is readonly there is not much we can tell about its
> value (apart from its default value?). This can be covered by tests
> exercising the value of the register from userspace.
>
> For PS_INVOCATION_COUNT we've got the following piglit tests :
>
>
> KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations
>
> Vulkan CTS tests :
>
>dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.*
>
> Signed-off-by: Lionel Landwerlin
> Fixes: 86554f48e511 ("drm/i915/selftests: Verify whitelist of context
> registers")
> ---
> drivers/gpu/drm/i915/gt/selftest_workarounds.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index f12cb20fe785..a06f96df1bfd 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -926,6 +926,9 @@ check_whitelisted_registers(struct intel_engine_cs
> *engine,
>
> err = 0;
> for (i = 0; i < engine->whitelist.count; i++) {
> + if (engine->whitelist.list[i].reg.reg &
> RING_FORCE_TO_NONPRIV_RD)
> + continue;
> +
> if (!fn(engine, a[i], b[i], engine->whitelist.list[i].reg))
> err = -EINVAL;
> }
> --
> 2.21.0.392.gf8f6787159e
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/icl: whitelist PS_(DEPTH|INVOCATION)_COUNT
On Thu, Jun 20, 2019 at 2:27 AM Lionel Landwerlin wrote: > > The same tests failing on CFL+ platforms are also failing on ICL. > Documentation doesn't list the > WaAllowPMDepthAndInvocationCountAccessFromUMD workaround for ICL but > applying it fixes the same tests as CFL. > > Signed-off-by: Lionel Landwerlin > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 367f5cc5965f..331a0050154d 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -1131,6 +1131,12 @@ static void icl_whitelist_build(struct intel_engine_cs > *engine) > > /* WaEnableStateCacheRedirectToCS:icl */ > whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1); > + > + /* WaAllowPMDepthAndInvocationCountAccessFromUMD:icl */ > + whitelist_reg(w, PS_DEPTH_COUNT); > + whitelist_reg(w, PS_DEPTH_COUNT_UDW); > + whitelist_reg(w, PS_INVOCATION_COUNT); > + whitelist_reg(w, PS_INVOCATION_COUNT_UDW); > break; > > case VIDEO_DECODE_CLASS: > -- > 2.21.0.392.gf8f6787159e > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx Tested-by: Anuj Phogat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1
On Sun, Apr 28, 2019 at 10:57 PM Tvrtko Ursulin wrote: > > > On 26/04/2019 17:58, Anuj Phogat wrote: > > > > Joonas, > > > > Mesa now applies this WA on ICL and we're not seeing any regressions in CI. > > I tested Mesa with and without this patch applied to kernel. I don't see > > any > > performance impact to Manhattan from GfxBench5. I'm little surprised to > > see it's not really helping benchmark performance in Mesa. I'll dig bit > > more > > to figure out a possible explanation. I haven't tried any other benchmarks > > with this patch. > > I think the concern was, if user is running old Mesa (no WA) on new > kernel (no WA) there wouldn't be any GPU hangs, just theoretical (yet > unmeasured) perf drop? > I also tested Manhattan with Mesa (no WA) and Kernel (no WA) and didn't see a GPU hang or any perf drop. The no change in perf might be due to currently used L3 configuration in Mesa which doesn't allocate anything to CS Command buffer section. Mesa now carries the WA in case we choose to use a different L3 config in future. > Regards, > > Tvrtko > > > > > Thanks > > Anuj > > On 04/26/2019 01:31 AM, Joonas Lahtinen wrote: > >> + Anuj > >> > >> Quoting Lionel Landwerlin (2019-04-26 11:13:58) > >>> On 18/04/2019 18:06, Tvrtko Ursulin wrote: > >>>> From: Tvrtko Ursulin > >>>> > >>>> WaEnableStateCacheRedirectToCS context workaround configures the L3 > >>>> cache > >>>> to benefit 3d workloads but media has different requirements. > >>>> > >>>> Remove the workaround and whitelist the register to allow any userspace > >>>> configure the behaviour to their liking. > >>>> > >>>> v2: > >>>>* Remove the workaround apart from adding the whitelist. > >>>> > >>>> Signed-off-by: Tvrtko Ursulin > >>>> Cc: Lionel Landwerlin > >>>> Cc: kevin...@intel.com > >>>> Cc: xiaogang...@intel.com > >>> > >>> Acked-by: Lionel Landwerlin > >>> > >>> > >>> Mesa commits : > >>> > >>> commit db5b372bb9f5a0dfea86618f8f9832f25d9eaf71 (anv) > >>> > >>> commit eaadb62c9ea98f841d7ffc26c14341abdf84d2d6 (i965) > >>> > >>> commit d1be67db39463b48369cb71979ed18662b2c157e (iris) > >> Could somebody confirm that applying this patch does not cause hangs in > >> older mesa, and the performance drop (if any) is insignificant? > >> > >> Best Regards, > >> Joonas > > > > > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1
On Thu, Apr 18, 2019 at 3:06 AM Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > WaEnableStateCacheRedirectToCS context workaround configures the L3 cache > to benefit 3d workloads but media has different requirements. > > Remove the workaround and whitelist the register to allow any userspace > configure the behaviour to their liking. > > v2: > * Remove the workaround apart from adding the whitelist. > > Signed-off-by: Tvrtko Ursulin > Cc: Lionel Landwerlin > Cc: kevin...@intel.com > Cc: xiaogang...@intel.com > --- > drivers/gpu/drm/i915/intel_workarounds.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c > b/drivers/gpu/drm/i915/intel_workarounds.c > index b3cbed1ee1c9..baed186724d2 100644 > --- a/drivers/gpu/drm/i915/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/intel_workarounds.c > @@ -556,10 +556,6 @@ static void icl_ctx_workarounds_init(struct > intel_engine_cs *engine) > WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, > GEN11_TDL_CLOCK_GATING_FIX_DISABLE); > > - /* WaEnableStateCacheRedirectToCS:icl */ > - WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN1, > - GEN11_STATE_CACHE_REDIRECT_TO_CS); > - > /* Wa_2006665173:icl (pre-prod) */ > if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_A0)) > WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3, > @@ -1070,6 +1066,9 @@ static void icl_whitelist_build(struct i915_wa_list *w) > > /* WaAllowUMDToModifySamplerMode:icl */ > whitelist_reg(w, GEN10_SAMPLER_MODE); > + > + /* WaEnableStateCacheRedirectToCS:icl */ > + whitelist_reg(w, GEN9_SLICE_COMMON_ECO_CHICKEN1); > } > > void intel_engine_init_whitelist(struct intel_engine_cs *engine) > -- > 2.19.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx Acked-by: Anuj Phogat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1
Joonas, Mesa now applies this WA on ICL and we're not seeing any regressions in CI. I tested Mesa with and without this patch applied to kernel. I don't see any performance impact to Manhattan from GfxBench5. I'm little surprised to see it's not really helping benchmark performance in Mesa. I'll dig bit more to figure out a possible explanation. I haven't tried any other benchmarks with this patch. Thanks Anuj On 04/26/2019 01:31 AM, Joonas Lahtinen wrote: + Anuj Quoting Lionel Landwerlin (2019-04-26 11:13:58) On 18/04/2019 18:06, Tvrtko Ursulin wrote: From: Tvrtko Ursulin WaEnableStateCacheRedirectToCS context workaround configures the L3 cache to benefit 3d workloads but media has different requirements. Remove the workaround and whitelist the register to allow any userspace configure the behaviour to their liking. v2: * Remove the workaround apart from adding the whitelist. Signed-off-by: Tvrtko Ursulin Cc: Lionel Landwerlin Cc: kevin...@intel.com Cc: xiaogang...@intel.com Acked-by: Lionel Landwerlin Mesa commits : commit db5b372bb9f5a0dfea86618f8f9832f25d9eaf71 (anv) commit eaadb62c9ea98f841d7ffc26c14341abdf84d2d6 (i965) commit d1be67db39463b48369cb71979ed18662b2c157e (iris) Could somebody confirm that applying this patch does not cause hangs in older mesa, and the performance drop (if any) is insignificant? Best Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads
Fixes multiple gpu hangs in piglit and vulkancts.
Both patches are:
Tested-by: Anuj Phogat
On Tue, Mar 5, 2019 at 4:48 AM Michał Winiarski
wrote:
>
> We assumed that the default preemption granularity is fine for ICL.
> Unfortunately, it turns out that some drivers don't support mid-thread
> preemption for compute workloads.
> If a workload that doesn't support mid-thread preemption gets mid-thread
> preempted, we're going to observe a GPU hang.
> While I'm here, let's also update the "workaround" naming.
>
> Signed-off-by: Michał Winiarski
> Cc: Anuj Phogat
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: Rafael Antognolli
> Tested-by: Anuj Phogat
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 89b4007d5200..2fba33509f4e 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine)
>GEN10_CACHE_MODE_SS,
>0, /* write-only, so skip validation */
>
> _MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
> +
> + /* WaDisableGPGPUMidThreadPreemption:icl */
> + WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> + GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> + GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> }
>
> void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
> @@ -1162,8 +1167,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> + if (IS_GEN_RANGE(i915, 9, 11)) {
> + /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
> wa_masked_en(wal,
> GEN7_FF_SLICE_CS_CHICKEN1,
> GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads
Tested both the patches with drm-tip kernel. Fixes multiple gpu hangs
in vulkan cts and piglit. I will do more thorough testing with updated
version of these patches based on review.
On Wed, Feb 27, 2019 at 7:52 AM Michał Winiarski
wrote:
>
> We assumed that the default preemption granularity is fine for ICL.
> Unfortunately, it turns out that some drivers don't support mid-thread
> preemption for compute workloads.
> If a workload that doesn't support mid-thread preemption gets mid-thread
> preempted, we're going to observe a GPU hang.
> While I'm here, let's also update the "workaround" naming.
>
> Signed-off-by: Michał Winiarski
> Cc: Anuj Phogat
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 743cf5b00155..a19e1c0052a7 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -555,6 +555,11 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine)
>GEN10_CACHE_MODE_SS,
>0, /* write-only, so skip validation */
>
> _MASKED_BIT_ENABLE(FLOAT_BLEND_OPTIMIZATION_ENABLE));
> +
> + /* WaDisableGPGPUMidThreadPreemption:icl */
> + WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
> + GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> + GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
> }
>
> void intel_engine_init_ctx_wa(struct intel_engine_cs *engine)
> @@ -1170,8 +1175,8 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> - /*
> WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> + if (IS_GEN_RANGE(i915, 9, 11)) {
> + /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl */
> wa_masked_en(wal,
> GEN7_FF_SLICE_CS_CHICKEN1,
> GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/icl: Add Wa_1406609255
On Fri, Sep 28, 2018 at 9:50 AM Radhakrishna Sripada
wrote:
>
> Shader feature to prefetch binding tables does not support 16:6 18:8 BTP
> formats. Enabling fault handling could result in hangs with faults.
> Disabling demand prefetch would disable binding table prefetch.
>
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_workarounds.c | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4b472bc2d26d..117ae5bf647c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7411,6 +7411,9 @@ enum {
> #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
> #define GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
>
> +#define GEN7_SARCHKMD _MMIO(0xB000)
> +#define GEN7_DISABLE_DEMAND_PREFETCH (1 << 31)
> +
> #define GEN7_L3SQCREG1 _MMIO(0xB010)
> #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
>
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 54a63c9b694f..9d5f48b98803 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -909,6 +909,12 @@ static void icl_gt_workarounds_apply(struct
> drm_i915_private *dev_priv)
> /* WaEnable32PlaneMode:icl */
> I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
>_MASKED_BIT_ENABLE(GEN11_ENABLE_32_PLANE_MODE));
> +
> + /* Wa_1406609255:icl (pre-prod) */
> + if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_C0))
> + I915_WRITE(GEN7_SARCHKMD,
> + I915_READ(GEN7_SARCHKMD) |
> + GEN7_DISABLE_DEMAND_PREFETCH);
> }
>
> void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> --
> 2.9.3
>
> _______
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Tested and Reviewed-by: Anuj Phogat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V2] drm/i915/icl:Add Wa_1606682166
Incorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes.
Disable the Sampler state prefetch functionality in the SARB by
programming 0xB000[30] to '1'. This is to be done at boot time
and the feature must remain disabled permanently.
Fixes flaky tex-mip-level-selection* piglit tests with Mesa i965
driver.
Cc: Radhakrishna Sripada
Signed-off-by: Anuj Phogat
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dd422c4..528b449 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7475,6 +7475,7 @@ enum {
#define GEN7_SARCHKMD _MMIO(0xB000)
#define GEN7_DISABLE_DEMAND_PREFETCH (1 << 31)
+#define GEN7_DISABLE_SAMPLER_PREFETCH (1 << 30)
#define GEN7_L3SQCREG1 _MMIO(0xB010)
#define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 620111b..5589611 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -939,7 +939,8 @@ static void icl_gt_workarounds_apply(struct
drm_i915_private *dev_priv)
if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_C0))
I915_WRITE(GEN7_SARCHKMD,
I915_READ(GEN7_SARCHKMD) |
- GEN7_DISABLE_DEMAND_PREFETCH);
+ GEN7_DISABLE_DEMAND_PREFETCH |
+ GEN7_DISABLE_SAMPLER_PREFETCH);
}
static void tgl_gt_workarounds_apply(struct drm_i915_private *dev_priv)
--
2.4.11
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Add Wa_1606682166
Incorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes.
Disable the Sampler state prefetch functionality in the SARB by
programming 0xB000[30] to '1'. This is to be done at boot time
and the feature must remain disabled permanently.
Fixes flaky tex-mip-level-selection* piglit tests with Mesa i965
driver.
Cc: Radhakrishna Sripada
Signed-off-by: Anuj Phogat
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dd422c4..528b449 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7475,6 +7475,7 @@ enum {
#define GEN7_SARCHKMD _MMIO(0xB000)
#define GEN7_DISABLE_DEMAND_PREFETCH (1 << 31)
+#define GEN7_DISABLE_SAMPLER_PREFETCH (1 << 30)
#define GEN7_L3SQCREG1 _MMIO(0xB010)
#define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 620111b..5589611 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -939,7 +939,8 @@ static void icl_gt_workarounds_apply(struct
drm_i915_private *dev_priv)
if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_C0))
I915_WRITE(GEN7_SARCHKMD,
I915_READ(GEN7_SARCHKMD) |
- GEN7_DISABLE_DEMAND_PREFETCH);
+ GEN7_DISABLE_DEMAND_PREFETCH |
+ GEN7_DISABLE_SAMPLER_PREFETCH);
}
static void tgl_gt_workarounds_apply(struct drm_i915_private *dev_priv)
--
2.4.11
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915/icl: WaEnableFloatBlendOptimization"
On Mon, Aug 6, 2018 at 9:14 AM Chris Wilson wrote: > Quoting Anuj Phogat (2018-08-03 20:24:09) > > > > > > On Mon, Jul 30, 2018 at 5:07 AM Mika Kuoppala < > mika.kuopp...@linux.intel.com> > > wrote: > > > > The register for 0xe420 is unable to hold any value, including > > this bit. The documentation is also mixed between having a > > register bit for toggle and having a state command setup > > for it. Apparently the register toggle is deprecated. > > > > > > CACHE_MODE_SS is not listed in > > a > > gfxspecs table > > which lists all > > user mode > > non-privileged registers. So, > > do you think > > making any changes > > to the register > > from mesa will hold? > > No, a privileged write to the register from inside the ring didn't > stick, so something is amiss. > ok. Mika's commit message confused me where he mentioned about adding back the state setup for this bit in mesa. But, as I understand now the changes won't stick in the register. So, no changes required in mesa. -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915/icl: WaEnableFloatBlendOptimization"
On Mon, Jul 30, 2018 at 5:07 AM Mika Kuoppala
wrote:
> The register for 0xe420 is unable to hold any value, including
> this bit. The documentation is also mixed between having a
> register bit for toggle and having a state command setup
> for it. Apparently the register toggle is deprecated.
>
> CACHE_MODE_SS is not listed in
a
gfxspecs table
which lists all
user mode
non-privileged registers. So,
do you think
making any changes
to the register
from mesa will hold?
> Remove the register toggle as evidence shows it's futile.
>
> The thing remaining is an apology and humble request for
> Mesa folks to resurrect their state setup for this as they
> were on right track from start.
>
> This reverts commit 0bf059f3532bb39c52d917142206a8554fc2f1c5.
>
> Fixes: 0bf059f3532b ("drm/i915/icl: WaEnableFloatBlendOptimization")
> References: HSDES#1406393558
> Cc: Oscar Mateo
> Cc: Anuj Phogat
> Cc: Chris Wilson
> Cc: Lionel Landwerlin
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ---
> drivers/gpu/drm/i915/intel_workarounds.c | 3 ---
> 2 files changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 7bdc214ffb6e..e0f5999fff07 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2859,9 +2859,6 @@ enum i915_power_well_id {
> #define GEN8_4x4_STC_OPTIMIZATION_DISABLE(1 << 6)
> #define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1 << 1)
>
> -#define GEN10_CACHE_MODE_SS_MMIO(0xe420)
> -#define FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
> -
> #define GEN6_BLITTER_ECOSKPD _MMIO(0x221d0)
> #define GEN6_BLITTER_LOCK_SHIFT 16
> #define GEN6_BLITTER_FBC_NOTIFY (1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index f8bb32e974f6..4bcdeaf8d98f 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -508,9 +508,6 @@ static int icl_ctx_workarounds_init(struct
> drm_i915_private *dev_priv)
> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
>
> - /* WaEnableFloatBlendOptimization:icl */
> - WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS,
> FLOAT_BLEND_OPTIMIZATION_ENABLE);
> -
> return 0;
> }
>
> --
> 2.17.1
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization
On Tue, May 29, 2018 at 5:47 AM, Lionel Landwerlin
wrote:
> FYI, we're setting this in Mesa :
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130
> https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67
> I don't think we realized this was a privileged register.
>
No, I didn't.
> Anuj: Maybe we can drop it?
>
Yes, I'll send out patches to remove it from Mesa.
> -
> Lionel
>
>
> On 29/05/18 13:07, Mika Kuoppala wrote:
>>
>> Oscar Mateo writes:
>>
>>> Enables blend optimization for floating point RTs
>>>
>>> v2: Rebased on top of the WA refactoring
>>> v3: Added References (Mika)
>>>
>>> References: HSDES#1406393558
>>> Cc: Mika Kuoppala
>>> Signed-off-by: Oscar Mateo
>>
>> Let's see if we can get away without whitelisting this,
>> Reviewed-by: Mika Kuoppala
>>
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h | 3 +++
>>> drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
>>> 2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index 6e88c6b..f123c3e 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -2663,6 +2663,9 @@ enum i915_power_well_id {
>>> #define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1<<6)
>>> #define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1<<1)
>>> +#define GEN10_CACHE_MODE_SS _MMIO(0xe420)
>>> +#define FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
>>> +
>>> #define GEN6_BLITTER_ECOSKPD _MMIO(0x221d0)
>>> #define GEN6_BLITTER_LOCK_SHIFT 16
>>> #define GEN6_BLITTER_FBC_NOTIFY (1<<3)
>>> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
>>> b/drivers/gpu/drm/i915/intel_workarounds.c
>>> index 33a1a0c..e9c00b0 100644
>>> --- a/drivers/gpu/drm/i915/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
>>> @@ -479,6 +479,9 @@ static int icl_ctx_workarounds_init(struct
>>> drm_i915_private *dev_priv)
>>> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
>>> GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
>>> + /* WaEnableFloatBlendOptimization:icl */
>>> + WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS,
>>> FLOAT_BLEND_OPTIMIZATION_ENABLE);
>>> +
>>> return 0;
>>> }
>>>
>>> --
>>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/20] drm/i915/icl: Add the ICL PCI IDs
On Tue, Feb 13, 2018 at 8:37 AM, Mika Kuoppala <
mika.kuopp...@linux.intel.com> wrote:
> From: Paulo Zanoni
>
> This is the current PCI ID list in our documentation.
>
> Let's leave the _gt#_ part out for now since our current documentation
> is not 100% clear and we don't need this info now anyway.
>
> v2: Use the new ICL_11 naming (Kelvin Gardiner).
> v3: Latest IDs as per BSpec (Oscar).
> v4: Make it compile (Paulo).
> v5: Remove comments (Lucas).
> v6: Multile rebases (Paulo).
> v7: Rebase (Mika)
>
> Reviewed-by: Anuj Phogat (v1)
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Oscar Mateo
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> include/drm/i915_pciids.h | 12
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 4e7a10c89782..c94a76bef763 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -650,6 +650,7 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_CFL_U_GT2_IDS(&intel_coffeelake_gt2_info),
> INTEL_CFL_U_GT3_IDS(&intel_coffeelake_gt3_info),
> INTEL_CNL_IDS(&intel_cannonlake_info),
> + INTEL_ICL_11_IDS(&intel_icelake_11_info),
> {0, 0, 0}
> };
> MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 9e1fe6634424..4afcdb4492f1 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -430,4 +430,16 @@
> INTEL_VGA_DEVICE(0x5A5C, info), \
> INTEL_VGA_DEVICE(0x5A44, info)
>
> +/* ICL */
> +#define INTEL_ICL_11_IDS(info) \
> + INTEL_VGA_DEVICE(0x8A50, info), \
> + INTEL_VGA_DEVICE(0x8A51, info), \
> + INTEL_VGA_DEVICE(0x8A5C, info), \
> + INTEL_VGA_DEVICE(0x8A5D, info), \
> + INTEL_VGA_DEVICE(0x8A52, info), \
> + INTEL_VGA_DEVICE(0x8A5A, info), \
> + INTEL_VGA_DEVICE(0x8A5B, info), \
> + INTEL_VGA_DEVICE(0x8A71, info), \
> + INTEL_VGA_DEVICE(0x8A70, info)
>
Why do we need a GT0 pci id in there?
> +
> #endif /* _I915_PCIIDS_H */
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
On Thu, Jan 11, 2018 at 10:31 AM, Rodrigo Vivi wrote: > On Thu, Jan 11, 2018 at 06:20:53PM +0000, Anuj Phogat wrote: >> Rodrigo, Can you push it upstream for me? > > I just pushed the libdrm. > > Do I also need to push the mesa one? > No, I've pushed the mesa patch. Thanks. > Thanks, > Rodrigo. > >> >> Thanks >> Anuj >> >> On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi wrote: >> > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote: >> >> Cc: Rodrigo Vivi >> >> Cc: Anusha Srivatsa >> >> Signed-off-by: Anuj Phogat >> > >> > Reviewed-by: Rodrigo Vivi >> > >> >> --- >> >> intel/intel_chipset.h | 30 +++--- >> >> 1 file changed, 23 insertions(+), 7 deletions(-) >> >> >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> >> index d81b1646..3818e71e 100644 >> >> --- a/intel/intel_chipset.h >> >> +++ b/intel/intel_chipset.h >> >> @@ -223,15 +223,23 @@ >> >> >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 >> >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 >> >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A >> >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B >> >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 >> >> >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52 >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A >> >> @@ -477,17 +485,25 @@ >> >> >> >> #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 >> >> || \ >> >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) >> >> >> >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) >> >> >> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 >> >> || \ >> >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 >> >> || \ >> >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) >> >> >> >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ >> >> IS_CFL_H(devid) || \ >> >> -- >> >> 2.13.6 >> >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
Rodrigo, Can you push it upstream for me? Thanks Anuj On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi wrote: > On Wed, Jan 10, 2018 at 11:51:02PM +0000, Anuj Phogat wrote: >> Cc: Rodrigo Vivi >> Cc: Anusha Srivatsa >> Signed-off-by: Anuj Phogat > > Reviewed-by: Rodrigo Vivi > >> --- >> intel/intel_chipset.h | 30 +++--- >> 1 file changed, 23 insertions(+), 7 deletions(-) >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> index d81b1646..3818e71e 100644 >> --- a/intel/intel_chipset.h >> +++ b/intel/intel_chipset.h >> @@ -223,15 +223,23 @@ >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 >> #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 >> #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 >> #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52 >> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A >> @@ -477,17 +485,25 @@ >> >> #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \ >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) >> >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) >> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \ >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \ >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) >> >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ >> IS_CFL_H(devid) || \ >> -- >> 2.13.6 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
Cc: Rodrigo Vivi Cc: Anusha Srivatsa Signed-off-by: Anuj Phogat --- intel/intel_chipset.h | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index d81b1646..3818e71e 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -223,15 +223,23 @@ #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 #define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52 #define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A @@ -477,17 +485,25 @@ #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 || \ (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 || \ + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 || \ (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 || \ (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \ - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 || \ + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \ (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \ (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \ - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \ + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ IS_CFL_H(devid) || \ -- 2.13.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915_pciids: Change a KBL pci id to GT2 from GT1.5
On Thu, Sep 21, 2017 at 2:58 PM, Rodrigo Vivi wrote:
> In sync with 41693fd52373 ("drm/i915/kbl: Change a KBL pci id
> to GT2 from GT1.5")
>
> "See Mesa commit 9c588ff"
>
> Cc: Anuj Phogat
> Signed-off-by: Rodrigo Vivi
> ---
> lib/i915_pciids.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
> index 3e4f9614..0d2b125c 100644
> --- a/lib/i915_pciids.h
> +++ b/lib/i915_pciids.h
> @@ -303,7 +303,6 @@
> #define INTEL_KBL_GT1_IDS(info)\
> INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
> INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
> - INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
> INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
> @@ -313,6 +312,7 @@
>
> #define INTEL_KBL_GT2_IDS(info)\
> INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
> + INTEL_VGA_DEVICE(0x5917, info), /* DT GT2 */ \
Mobile GT2
> INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
> INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
> INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
> --
> 2.13.5
>
With above change:
Reviewed-by: Anuj Phogat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm V2 2/2] intel: Change a KBL pci id to GT2 from GT1.5
On Wed, Sep 20, 2017 at 2:35 PM, Rodrigo Vivi wrote: > On Wed, Sep 20, 2017 at 07:11:03PM +0000, Anuj Phogat wrote: >> See Mesa commit 9c588ff >> >> Cc: Matt Turner >> Cc: Rodrigo Vivi >> Signed-off-by: Anuj Phogat > > Reviewed-by: Rodrigo Vivi > Rodrigo, I don't have push permissions. Can you push it for me? >> --- >> intel/intel_chipset.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> index 3ff59ada..d81b1646 100644 >> --- a/intel/intel_chipset.h >> +++ b/intel/intel_chipset.h >> @@ -202,7 +202,7 @@ >> #define PCI_CHIP_KABYLAKE_ULX_GT10x590E >> #define PCI_CHIP_KABYLAKE_ULX_GT20x591E >> #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 >> -#define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 >> +#define PCI_CHIP_KABYLAKE_M_GT2 0x5917 >> #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 >> #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B >> #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B >> @@ -434,7 +434,6 @@ >> >> #define IS_KBL_GT1(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT1_5 || \ >>(devid) == PCI_CHIP_KABYLAKE_ULX_GT1_5 || \ >> - (devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ >>(devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ >>(devid) == PCI_CHIP_KABYLAKE_ULX_GT1 || \ >>(devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ >> @@ -446,6 +445,7 @@ >>(devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ >>(devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ >>(devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ >> + (devid) == PCI_CHIP_KABYLAKE_M_GT2 || \ >>(devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ >>(devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \ >>(devid) == PCI_CHIP_KABYLAKE_WKS_GT2) >> -- >> 2.13.5 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
On Wed, Sep 20, 2017 at 2:34 PM, Rodrigo Vivi wrote: > On Wed, Sep 20, 2017 at 08:31:26PM +0000, Anuj Phogat wrote: >> See Mesa commit 9c588ff >> >> Cc: Matt Turner >> Cc: Rodrigo Vivi >> Signed-off-by: Anuj Phogat > > Reviewed-by: Rodrigo Vivi > Thanks Rodrigo. Can you push it for me? >> --- >> include/drm/i915_pciids.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h >> index 1257e15c1a03..972a25633525 100644 >> --- a/include/drm/i915_pciids.h >> +++ b/include/drm/i915_pciids.h >> @@ -339,7 +339,6 @@ >> #define INTEL_KBL_GT1_IDS(info) \ >> INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \ >> INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \ >> - INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \ >> INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \ >> INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \ >> INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \ >> @@ -349,6 +348,7 @@ >> >> #define INTEL_KBL_GT2_IDS(info) \ >> INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \ >> + INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ >> INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \ >> INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \ >> INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \ >> -- >> 2.13.5 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
See Mesa commit 9c588ff Cc: Matt Turner Cc: Rodrigo Vivi Signed-off-by: Anuj Phogat --- include/drm/i915_pciids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 1257e15c1a03..972a25633525 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -339,7 +339,6 @@ #define INTEL_KBL_GT1_IDS(info)\ INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \ INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \ - INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \ INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \ INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \ INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \ @@ -349,6 +348,7 @@ #define INTEL_KBL_GT2_IDS(info)\ INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \ + INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \ INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \ INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \ -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 2/2] intel: Change a KBL pci id to GT2 from GT1.5
On Wed, Sep 20, 2017 at 12:13 PM, Anuj Phogat wrote: > Any comments on this one. Sent out v2 after dropping > [PATCH 1/2] drm/i915/kbl: Remove unused Kabylake pci ids Correction. Dropped patch for libdrm is: [PATCH libdrm 1/2] intel: Remove unused Kabylake pci ids > > On Mon, Sep 11, 2017 at 9:22 AM, Anuj Phogat wrote: >> See Mesa commit 9c588ff >> >> Cc: Matt Turner >> Cc: Rodrigo Vivi >> Signed-off-by: Anuj Phogat >> --- >> intel/intel_chipset.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> index 77a9ca6..6bd8ae2 100644 >> --- a/intel/intel_chipset.h >> +++ b/intel/intel_chipset.h >> @@ -198,7 +198,7 @@ >> #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 >> #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E >> #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 >> -#define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 >> +#define PCI_CHIP_KABYLAKE_M_GT20x5917 >> #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 >> #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B >> #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B >> @@ -424,8 +424,7 @@ >> (devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ >> (devid) == PCI_CHIP_SKYLAKE_WKS_GT4) >> >> -#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ >> -(devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ >> +#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ >> (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ >> (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1) >> >> @@ -433,6 +432,7 @@ >> (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ >> (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ >> (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ >> +(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \ >> (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ >> (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) >> >> -- >> 2.9.4 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 1/2] intel: Remove unused Kabylake pci ids
Dropping this patch. On Mon, Sep 11, 2017 at 9:22 AM, Anuj Phogat wrote: > These PCI IDs are not used in any Kabylake SKUs. > See Mesa commits: ebc5ccf and b2dae9f > > Cc: Matt Turner > Cc: Rodrigo Vivi > Signed-off-by: Anuj Phogat > --- > intel/intel_chipset.h | 26 -- > 1 file changed, 4 insertions(+), 22 deletions(-) > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h > index 3ff59ad..77a9ca6 100644 > --- a/intel/intel_chipset.h > +++ b/intel/intel_chipset.h > @@ -192,24 +192,16 @@ > #define PCI_CHIP_SKYLAKE_WKS_GT4 0x193D > > #define PCI_CHIP_KABYLAKE_ULT_GT2 0x5916 > -#define PCI_CHIP_KABYLAKE_ULT_GT1_50x5913 > #define PCI_CHIP_KABYLAKE_ULT_GT1 0x5906 > -#define PCI_CHIP_KABYLAKE_ULT_GT3_00x5923 > #define PCI_CHIP_KABYLAKE_ULT_GT3_10x5926 > #define PCI_CHIP_KABYLAKE_ULT_GT3_20x5927 > #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 > -#define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915 > -#define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E > #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E > #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 > #define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 > #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 > #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B > -#define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B > -#define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908 > #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B > -#define PCI_CHIP_KABYLAKE_SRV_GT2 0x591A > -#define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A > #define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D > > #define PCI_CHIP_BROXTON_0 0x0A84 > @@ -432,34 +424,24 @@ > (devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ > (devid) == PCI_CHIP_SKYLAKE_WKS_GT4) > > -#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1_5 || \ > -(devid) == PCI_CHIP_KABYLAKE_ULX_GT1_5 || \ > -(devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ > +#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ > (devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ > -(devid) == PCI_CHIP_KABYLAKE_ULX_GT1 || \ > (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ > -(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_0 || \ > -(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1 || \ > -(devid) == PCI_CHIP_KABYLAKE_SRV_GT1) > +(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1) > > #define IS_KBL_GT2(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ > (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ > (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ > -(devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) > > -#define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \ > -(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \ > +#define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \ > (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2) > > -#define IS_KBL_GT4(devid) ((devid) == PCI_CHIP_KABYLAKE_HALO_GT4) > - > #define IS_KABYLAKE(devid) (IS_KBL_GT1(devid) || \ > IS_KBL_GT2(devid) || \ > -IS_KBL_GT3(devid) || \ > -IS_KBL_GT4(devid)) > +IS_KBL_GT3(devid)) > > #define IS_SKYLAKE(devid) (IS_SKL_GT1(devid) || \ > IS_SKL_GT2(devid) || \ > -- > 2.9.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 2/2] intel: Change a KBL pci id to GT2 from GT1.5
Any comments on this one. Sent out v2 after dropping [PATCH 1/2] drm/i915/kbl: Remove unused Kabylake pci ids On Mon, Sep 11, 2017 at 9:22 AM, Anuj Phogat wrote: > See Mesa commit 9c588ff > > Cc: Matt Turner > Cc: Rodrigo Vivi > Signed-off-by: Anuj Phogat > --- > intel/intel_chipset.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h > index 77a9ca6..6bd8ae2 100644 > --- a/intel/intel_chipset.h > +++ b/intel/intel_chipset.h > @@ -198,7 +198,7 @@ > #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 > #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E > #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 > -#define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 > +#define PCI_CHIP_KABYLAKE_M_GT20x5917 > #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 > #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B > #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B > @@ -424,8 +424,7 @@ > (devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ > (devid) == PCI_CHIP_SKYLAKE_WKS_GT4) > > -#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ > -(devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ > +#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ > (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ > (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1) > > @@ -433,6 +432,7 @@ > (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ > (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ > +(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ > (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) > > -- > 2.9.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm V2 2/2] intel: Change a KBL pci id to GT2 from GT1.5
See Mesa commit 9c588ff Cc: Matt Turner Cc: Rodrigo Vivi Signed-off-by: Anuj Phogat --- intel/intel_chipset.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 3ff59ada..d81b1646 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -202,7 +202,7 @@ #define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 -#define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 +#define PCI_CHIP_KABYLAKE_M_GT20x5917 #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B @@ -434,7 +434,6 @@ #define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1_5 || \ (devid) == PCI_CHIP_KABYLAKE_ULX_GT1_5 || \ -(devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ (devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ (devid) == PCI_CHIP_KABYLAKE_ULX_GT1 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ @@ -446,6 +445,7 @@ (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ +(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/kbl: Remove unused Kabylake pci ids
Dropping this patch.
On Tue, Sep 12, 2017 at 5:31 PM, Rodrigo Vivi wrote:
> On Tue, Sep 12, 2017 at 08:30:47PM +, Paulo Zanoni wrote:
>> Em Seg, 2017-09-11 às 10:10 -0700, Rodrigo Vivi escreveu:
>> > On Mon, Sep 11, 2017 at 04:11:33PM +, Anuj Phogat wrote:
>> > > See Mesa commits: ebc5ccf and b2dae9f
>> >
>> > I believe we need to be in sync between multiple gfx stack
>> > components,
>> > but I don't believe we should remove ids.
>> >
>> > In the past we had cases where we noticed a product group using a
>> > listed
>> > id to do a product and we just noticed the id after a user reported
>> > at fd.o.
>>
>> On the other hand, don't we have the risk that someone is going to see
>> that these IDs are unused for KBL and them repurpose them om some
>> future non-KBL product?
>
> There is only risk if the id was removed from Spec. But when that happens I'm
> in favor
> of removing from the components as well.
> While it is listed there even without POR it is reserved.
>
>>
>> >
>> > For us in kernel the cycle until that id gets into a stable release
>> > propagated to OSVs distros can be a bit long.
>> >
>> > Also Xserver ids are nowadays in sync with Mesa ones and I believe
>> > some
>> > OSVs might take a while to upgrade the Xserver as well in case of a
>> > new
>> > found product with some "new" id.
>> >
>> > For this reason I was always in favor of adding all possible reserved
>> > ids from the
>> > beginning.
>> >
>> > And this approach worked well on BDW and SKL, where we've seeing
>> > later some
>> > reserved ids becoming real product and we didn't have to do any extra
>> > step.
>> >
>> > For this same reason I believe the right solution is to
>> > add those ids back to mesa instead of removing from kernel and
>> > libdrm.
>> >
>> > Thanks,
>> > Rodrigo.
>> >
>> > >
>> > > Cc: Matt Turner
>> > > Cc: Rodrigo Vivi
>> > > Signed-off-by: Anuj Phogat
>> > > ---
>> > > drivers/gpu/drm/i915/i915_pci.c | 1 -
>> > > include/drm/i915_pciids.h | 15 ++-
>> > > 2 files changed, 2 insertions(+), 14 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> > > b/drivers/gpu/drm/i915/i915_pci.c
>> > > index 129877b..ecf6d4c 100644
>> > > --- a/drivers/gpu/drm/i915/i915_pci.c
>> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
>> > > @@ -613,7 +613,6 @@ static const struct pci_device_id pciidlist[] =
>> > > {
>> > > INTEL_KBL_GT1_IDS(&intel_kabylake_gt1_info),
>> > > INTEL_KBL_GT2_IDS(&intel_kabylake_gt2_info),
>> > > INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),
>> > > - INTEL_KBL_GT4_IDS(&intel_kabylake_gt3_info),
>> > > INTEL_CFL_S_GT1_IDS(&intel_coffeelake_gt1_info),
>> > > INTEL_CFL_S_GT2_IDS(&intel_coffeelake_gt2_info),
>> > > INTEL_CFL_H_GT2_IDS(&intel_coffeelake_gt2_info),
>> > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
>> > > index 1257e15..a1bf90e 100644
>> > > --- a/include/drm/i915_pciids.h
>> > > +++ b/include/drm/i915_pciids.h
>> > > @@ -337,15 +337,10 @@
>> > > INTEL_VGA_DEVICE(0x3185, info)
>> > >
>> > > #define INTEL_KBL_GT1_IDS(info) \
>> > > - INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
>> > > - INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
>> > > INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
>> > > INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
>> > > - INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
>> > > INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
>> > > - INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
>> > > - INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
>> > > - INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
>> > > + INTEL_VGA_DEVICE(0x590B, info) /* Halo GT1 */
>> > >
>> > > #define INTEL_KBL_GT2_IDS(info) \
>> > > INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
>> > > @@ -353,22 +348,16 @@
>> > > INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
>> > > INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
>> > > INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2
Re: [Intel-gfx] [PATCH 1/2] drm/i915/kbl: Remove unused Kabylake pci ids
On Mon, Sep 11, 2017 at 10:10 AM, Rodrigo Vivi wrote:
> On Mon, Sep 11, 2017 at 04:11:33PM +0000, Anuj Phogat wrote:
>> See Mesa commits: ebc5ccf and b2dae9f
>
> I believe we need to be in sync between multiple gfx stack components,
> but I don't believe we should remove ids.
>
> In the past we had cases where we noticed a product group using a listed
> id to do a product and we just noticed the id after a user reported at fd.o.
>
> For us in kernel the cycle until that id gets into a stable release
> propagated to OSVs distros can be a bit long.
>
> Also Xserver ids are nowadays in sync with Mesa ones and I believe some
> OSVs might take a while to upgrade the Xserver as well in case of a new
> found product with some "new" id.
>
> For this reason I was always in favor of adding all possible reserved ids
> from the
> beginning.
>
> And this approach worked well on BDW and SKL, where we've seeing later some
> reserved ids becoming real product and we didn't have to do any extra step.
>
> For this same reason I believe the right solution is to
> add those ids back to mesa instead of removing from kernel and libdrm.
>
I'm fine with keeping the unused pci id's in Mesa tree and keep it uniform
across multiple gfx stack components. I'll revert the Mesa patch.
> Thanks,
> Rodrigo.
>
>>
>> Cc: Matt Turner
>> Cc: Rodrigo Vivi
>> Signed-off-by: Anuj Phogat
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 1 -
>> include/drm/i915_pciids.h | 15 ++-
>> 2 files changed, 2 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index 129877b..ecf6d4c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -613,7 +613,6 @@ static const struct pci_device_id pciidlist[] = {
>> INTEL_KBL_GT1_IDS(&intel_kabylake_gt1_info),
>> INTEL_KBL_GT2_IDS(&intel_kabylake_gt2_info),
>> INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),
>> - INTEL_KBL_GT4_IDS(&intel_kabylake_gt3_info),
>> INTEL_CFL_S_GT1_IDS(&intel_coffeelake_gt1_info),
>> INTEL_CFL_S_GT2_IDS(&intel_coffeelake_gt2_info),
>> INTEL_CFL_H_GT2_IDS(&intel_coffeelake_gt2_info),
>> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
>> index 1257e15..a1bf90e 100644
>> --- a/include/drm/i915_pciids.h
>> +++ b/include/drm/i915_pciids.h
>> @@ -337,15 +337,10 @@
>> INTEL_VGA_DEVICE(0x3185, info)
>>
>> #define INTEL_KBL_GT1_IDS(info) \
>> - INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
>> - INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
>> INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
>> INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
>> - INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
>> INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
>> - INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
>> - INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
>> - INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
>> + INTEL_VGA_DEVICE(0x590B, info) /* Halo GT1 */
>>
>> #define INTEL_KBL_GT2_IDS(info) \
>> INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
>> @@ -353,22 +348,16 @@
>> INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
>> INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
>> INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
>> - INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
>> INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
>>
>> #define INTEL_KBL_GT3_IDS(info) \
>> - INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
>> INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
>> INTEL_VGA_DEVICE(0x5927, info) /* ULT GT3 */
>>
>> -#define INTEL_KBL_GT4_IDS(info) \
>> - INTEL_VGA_DEVICE(0x593B, info) /* Halo GT4 */
>> -
>> #define INTEL_KBL_IDS(info) \
>> INTEL_KBL_GT1_IDS(info), \
>> INTEL_KBL_GT2_IDS(info), \
>> - INTEL_KBL_GT3_IDS(info), \
>> - INTEL_KBL_GT4_IDS(info)
>> + INTEL_KBL_GT3_IDS(info)
>>
>> /* CFL S */
>> #define INTEL_CFL_S_GT1_IDS(info) \
>> --
>> 2.9.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm 2/2] intel: Change a KBL pci id to GT2 from GT1.5
See Mesa commit 9c588ff Cc: Matt Turner Cc: Rodrigo Vivi Signed-off-by: Anuj Phogat --- intel/intel_chipset.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 77a9ca6..6bd8ae2 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -198,7 +198,7 @@ #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 -#define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 +#define PCI_CHIP_KABYLAKE_M_GT20x5917 #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B @@ -424,8 +424,7 @@ (devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ (devid) == PCI_CHIP_SKYLAKE_WKS_GT4) -#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ -(devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ +#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1) @@ -433,6 +432,7 @@ (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ +(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm 1/2] intel: Remove unused Kabylake pci ids
These PCI IDs are not used in any Kabylake SKUs. See Mesa commits: ebc5ccf and b2dae9f Cc: Matt Turner Cc: Rodrigo Vivi Signed-off-by: Anuj Phogat --- intel/intel_chipset.h | 26 -- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 3ff59ad..77a9ca6 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -192,24 +192,16 @@ #define PCI_CHIP_SKYLAKE_WKS_GT4 0x193D #define PCI_CHIP_KABYLAKE_ULT_GT2 0x5916 -#define PCI_CHIP_KABYLAKE_ULT_GT1_50x5913 #define PCI_CHIP_KABYLAKE_ULT_GT1 0x5906 -#define PCI_CHIP_KABYLAKE_ULT_GT3_00x5923 #define PCI_CHIP_KABYLAKE_ULT_GT3_10x5926 #define PCI_CHIP_KABYLAKE_ULT_GT3_20x5927 #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921 -#define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915 -#define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E #define PCI_CHIP_KABYLAKE_ULX_GT2 0x591E #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912 #define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917 #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B -#define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B -#define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908 #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B -#define PCI_CHIP_KABYLAKE_SRV_GT2 0x591A -#define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A #define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D #define PCI_CHIP_BROXTON_0 0x0A84 @@ -432,34 +424,24 @@ (devid) == PCI_CHIP_SKYLAKE_H_GT4 || \ (devid) == PCI_CHIP_SKYLAKE_WKS_GT4) -#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT1_5 || \ -(devid) == PCI_CHIP_KABYLAKE_ULX_GT1_5 || \ -(devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ +#define IS_KBL_GT1(devid) ((devid) == PCI_CHIP_KABYLAKE_DT_GT1_5 || \ (devid) == PCI_CHIP_KABYLAKE_ULT_GT1 || \ -(devid) == PCI_CHIP_KABYLAKE_ULX_GT1 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \ -(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_0 || \ -(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1 || \ -(devid) == PCI_CHIP_KABYLAKE_SRV_GT1) +(devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1) #define IS_KBL_GT2(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \ (devid) == PCI_CHIP_KABYLAKE_ULX_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \ (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \ -(devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \ (devid) == PCI_CHIP_KABYLAKE_WKS_GT2) -#define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \ -(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \ +#define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \ (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2) -#define IS_KBL_GT4(devid) ((devid) == PCI_CHIP_KABYLAKE_HALO_GT4) - #define IS_KABYLAKE(devid) (IS_KBL_GT1(devid) || \ IS_KBL_GT2(devid) || \ -IS_KBL_GT3(devid) || \ -IS_KBL_GT4(devid)) +IS_KBL_GT3(devid)) #define IS_SKYLAKE(devid) (IS_SKL_GT1(devid) || \ IS_SKL_GT2(devid) || \ -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/kbl: Remove unused Kabylake pci ids
See Mesa commits: ebc5ccf and b2dae9f
Cc: Matt Turner
Cc: Rodrigo Vivi
Signed-off-by: Anuj Phogat
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
include/drm/i915_pciids.h | 15 ++-
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 129877b..ecf6d4c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -613,7 +613,6 @@ static const struct pci_device_id pciidlist[] = {
INTEL_KBL_GT1_IDS(&intel_kabylake_gt1_info),
INTEL_KBL_GT2_IDS(&intel_kabylake_gt2_info),
INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),
- INTEL_KBL_GT4_IDS(&intel_kabylake_gt3_info),
INTEL_CFL_S_GT1_IDS(&intel_coffeelake_gt1_info),
INTEL_CFL_S_GT2_IDS(&intel_coffeelake_gt2_info),
INTEL_CFL_H_GT2_IDS(&intel_coffeelake_gt2_info),
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 1257e15..a1bf90e 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -337,15 +337,10 @@
INTEL_VGA_DEVICE(0x3185, info)
#define INTEL_KBL_GT1_IDS(info)\
- INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
- INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \
INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
- INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \
- INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
- INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
- INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+ INTEL_VGA_DEVICE(0x590B, info) /* Halo GT1 */
#define INTEL_KBL_GT2_IDS(info)\
INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
@@ -353,22 +348,16 @@
INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \
INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
- INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
#define INTEL_KBL_GT3_IDS(info) \
- INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x5927, info) /* ULT GT3 */
-#define INTEL_KBL_GT4_IDS(info) \
- INTEL_VGA_DEVICE(0x593B, info) /* Halo GT4 */
-
#define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
INTEL_KBL_GT2_IDS(info), \
- INTEL_KBL_GT3_IDS(info), \
- INTEL_KBL_GT4_IDS(info)
+ INTEL_KBL_GT3_IDS(info)
/* CFL S */
#define INTEL_CFL_S_GT1_IDS(info) \
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5
See Mesa commit 9c588ff Cc: Matt Turner Cc: Rodrigo Vivi Signed-off-by: Anuj Phogat --- include/drm/i915_pciids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index a1bf90e..1c29063 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -337,13 +337,13 @@ INTEL_VGA_DEVICE(0x3185, info) #define INTEL_KBL_GT1_IDS(info)\ - INTEL_VGA_DEVICE(0x5917, info), /* DT GT1.5 */ \ INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \ INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \ INTEL_VGA_DEVICE(0x590B, info) /* Halo GT1 */ #define INTEL_KBL_GT2_IDS(info)\ INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \ + INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \ INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \ INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \ -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Add Geminilake PCI IDs
On Thu, Nov 10, 2016 at 10:28 AM, Ben Widawsky wrote: > > From: Ben Widawsky > > Signed-off-by: Ben Widawsky > --- > intel/intel_chipset.h | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h > index 514f659..41fc0da 100644 > --- a/intel/intel_chipset.h > +++ b/intel/intel_chipset.h > @@ -218,6 +218,9 @@ > #define PCI_CHIP_BROXTON_3 0x1A85 > #define PCI_CHIP_BROXTON_4 0x5A85 > > +#define PCI_CHIP_GLK 0x3184 > +#define PCI_CHIP_GLK_2X6 0x3185 > + > #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \ > (devid) == PCI_CHIP_I915_GM || \ > (devid) == PCI_CHIP_I945_GM || \ > @@ -446,9 +449,13 @@ > (devid) == PCI_CHIP_BROXTON_3 || \ > (devid) == PCI_CHIP_BROXTON_4) > > -#define IS_GEN9(devid) (IS_SKYLAKE(devid) || \ > -IS_BROXTON(devid) || \ > -IS_KABYLAKE(devid)) > +#define IS_GEMINILAKE(devid) ((devid) == PCI_CHIP_GLK || \ > +(devid) == PCI_CHIP_GLK_2X6) > + > +#define IS_GEN9(devid) (IS_SKYLAKE(devid) || \ > +IS_BROXTON(devid) || \ > +IS_KABYLAKE(devid) || \ > +IS_GEMINILAKE(devid)) > > #define IS_9XX(dev)(IS_GEN3(dev) || \ > IS_GEN4(dev) || \ > -- > 2.10.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx IDs cross checked in graphics specs. Reviewed-by: Anuj Phogat ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function to initialize the
align variable in drm_intel_bo. Note that we continue ignoring the
alignment value passed to drm_intel_gem_bo_alloc() to follow the
previous behavior.
V2: Add a condition to avoid allocation from cache. (Ben)
V3: Make no changes in cache allocation strategy. Just update the alignment.
Update the aperture size estimate including the alignment. (Ben, Chris)
V4: Move aperture size adjustments inside
drm_intel_bo_gem_set_in_aperture_size()
Don't split sentences across the one-line header and the changelog. (Chris)
Signed-off-by: Anuj Phogat
Cc: Ben Widawsky
Cc: Chris Wilson
---
intel/intel_bufmgr_gem.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 60c06fc..3018081 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -82,6 +82,7 @@
} while (0)
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#define MAX2(A, B) ((A) > (B) ? (A) : (B))
typedef struct _drm_intel_bo_gem drm_intel_bo_gem;
@@ -524,9 +525,10 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int
need_fence)
static void
drm_intel_bo_gem_set_in_aperture_size(drm_intel_bufmgr_gem *bufmgr_gem,
- drm_intel_bo_gem *bo_gem)
+ drm_intel_bo_gem *bo_gem,
+ unsigned int alignment)
{
- int size;
+ unsigned int size;
assert(!bo_gem->used_as_reloc_target);
@@ -538,7 +540,7 @@ drm_intel_bo_gem_set_in_aperture_size(drm_intel_bufmgr_gem
*bufmgr_gem,
*/
size = bo_gem->bo.size;
if (bufmgr_gem->gen < 4 && bo_gem->tiling_mode != I915_TILING_NONE) {
- int min_size;
+ unsigned int min_size;
if (bufmgr_gem->has_relaxed_fencing) {
if (bufmgr_gem->gen == 3)
@@ -552,10 +554,10 @@
drm_intel_bo_gem_set_in_aperture_size(drm_intel_bufmgr_gem *bufmgr_gem,
min_size = size;
/* Account for worst-case alignment. */
- size = 2 * min_size;
+ alignment = MAX2(alignment, min_size);
}
- bo_gem->reloc_tree_size = size;
+ bo_gem->reloc_tree_size = size + alignment;
}
static int
@@ -660,7 +662,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
unsigned long size,
unsigned long flags,
uint32_t tiling_mode,
- unsigned long stride)
+ unsigned long stride,
+ unsigned int alignment)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
@@ -702,7 +705,9 @@ retry:
bucket->head.prev, head);
DRMLISTDEL(&bo_gem->head);
alloc_from_cache = true;
+ bo_gem->bo.align = alignment;
} else {
+ assert(alignment == 0);
/* For non-render-target BOs (where we're probably
* going to map it first thing in order to fill it
* with data), check if the last BO in the cache is
@@ -759,6 +764,7 @@ retry:
return NULL;
}
bo_gem->bo.bufmgr = bufmgr;
+ bo_gem->bo.align = alignment;
bo_gem->tiling_mode = I915_TILING_NONE;
bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
@@ -786,7 +792,7 @@ retry:
bo_gem->aub_annotations = NULL;
bo_gem->aub_annotation_count = 0;
- drm_intel_bo_gem_set_in_aperture_size(bufmgr_gem, bo_gem);
+ drm_intel_bo_gem_set_in_aperture_size(bufmgr_gem, bo_gem, alignment);
DBG("bo_create: buf %d (%s) %ldb\n",
bo_gem->gem_handle, bo_gem->name, size);
@@ -802,7 +808,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
BO_ALLOC_FOR_RENDER,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0,
+ alignme
[Intel-gfx] [PATCH v3 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
and use it to initialize the align variable in drm_intel_bo.
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function. Note that we continue
ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
the previous behavior.
V2: Add a condition to avoid allocation from cache. (Ben)
V3: Make no changes in cache allocation strategy. Just update the alignment.
Update the aperture size estimate including the alignment.
Signed-off-by: Anuj Phogat
Cc: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 60c06fc..6e711a5 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -660,7 +660,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
unsigned long size,
unsigned long flags,
uint32_t tiling_mode,
- unsigned long stride)
+ unsigned long stride,
+ unsigned int alignment)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
@@ -702,7 +703,9 @@ retry:
bucket->head.prev, head);
DRMLISTDEL(&bo_gem->head);
alloc_from_cache = true;
+ bo_gem->bo.align = alignment;
} else {
+ assert(alignment == 0);
/* For non-render-target BOs (where we're probably
* going to map it first thing in order to fill it
* with data), check if the last BO in the cache is
@@ -759,6 +762,7 @@ retry:
return NULL;
}
bo_gem->bo.bufmgr = bufmgr;
+ bo_gem->bo.align = alignment;
bo_gem->tiling_mode = I915_TILING_NONE;
bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
@@ -787,6 +791,8 @@ retry:
bo_gem->aub_annotation_count = 0;
drm_intel_bo_gem_set_in_aperture_size(bufmgr_gem, bo_gem);
+ /* Update the aperture size estimate assuming worst case */
+ bo_gem->reloc_tree_size += alignment;
DBG("bo_create: buf %d (%s) %ldb\n",
bo_gem->gem_handle, bo_gem->name, size);
@@ -802,7 +808,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
BO_ALLOC_FOR_RENDER,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0,
+ alignment);
}
static drm_intel_bo *
@@ -812,7 +819,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
unsigned int alignment)
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0, 0);
}
static drm_intel_bo *
@@ -864,7 +871,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
stride = 0;
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
- tiling, stride);
+ tiling, stride, 0);
}
static drm_intel_bo *
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Thu, Jun 25, 2015 at 12:17 PM, Ben Widawsky wrote: > On Thu, Jun 25, 2015 at 07:11:21PM +0100, Chris Wilson wrote: >> On Thu, Jun 25, 2015 at 11:01:44AM -0700, Ben Widawsky wrote: >> > On Wed, Jun 24, 2015 at 08:28:13AM +0100, Chris Wilson wrote: >> > > On Tue, Jun 23, 2015 at 04:44:52PM -0700, Anuj Phogat wrote: >> > > > On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson >> > > > wrote: >> > > > > On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote: >> > > > >> On Mon, Jun 22, 2015 at 11:47:02AM -0700, Anuj Phogat wrote: >> > > > >> > and use it to initialize the align variable in drm_intel_bo. >> > > > >> > >> > > > >> > In case of YF/YS tiled buffers libdrm need not know about the >> > > > >> > tiling >> > > > >> > format because these buffers don't have hardware support to be >> > > > >> > tiled >> > > > >> > or detiled through a fenced region. But, libdrm still need to know >> > > > >> > about buffer alignment restrictions because kernel uses it when >> > > > >> > resolving the relocation. >> > > > >> > >> > > > >> > Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys >> > > > >> > buffers. >> > > > >> > So, use the passed alignment value in this function. Note that we >> > > > >> > continue >> > > > >> > ignoring the alignment value passed to drm_intel_gem_bo_alloc() >> > > > >> > to follow >> > > > >> > the previous behavior. >> > > > >> > >> > > > >> > V2: Add a condition to avoid allocation from cache. (Ben) >> > > > >> >> > > > >> This will hurt badly since some programs love to cycle through >> > > > >> textures. >> > > > >> You can still allocate from the cache, you only need to update the >> > > > >> alignement constraint. The kernel will move the buffer on the next >> > > > >> execbuf >> > > > >> if it's misplaced. >> > > > > >> > > > > For llc, using fresh pages just puts memory and aperture pressure >> > > > > (plus >> > > > > a small amount of interface pressure) on the system by allocating >> > > > > more bo. >> > > > > >> > > > > For !llc, it is far better to move an object in the GTT to match a >> > > > > change in alignment than it is to allocate fresh pages (and >> > > > > deallocate >> > > > > stale pages). >> > > > Could you please explain this and point me to what you want to be >> > > > changed in this patch? >> > > >> > > You can reuse the cached bo if the alignment mismatches. You can >> > > experiment with searching for a better match, but it's unlikely to be >> > > useful (numbers talk here). >> > >> > There's no "better" match, there's only match or no match. It seems pretty >> > intuitive to me that trying to find a match would be better though, I'm >> > curious why you think it's unlikely. Even though we don't specifically get >> > the >> > alignment back from the kernel after the relocation, we can certainly use >> > the >> > presumed offset as a guess when trying to find a buffer in the cache. >> >> I was thinking in terms of cycles saved, the cost of walking the cache >> for an exact match vs returning the first available buffer + the cost of >> any relocation, and whether there would be a measurable difference. I >> would have thought two patches, do the naive search that doesn't require >> any changes to the cached allocation strategy then a second >> demonstrating the perf improvement from being a bit smarter in buffer >> reuse would have been your ideal anyway. >> -Chris > > That's exactly what I suggested Anuj do :-) Thanks for helping me to find the right fix. I'll send out an updated patch doing the naive search with passed alignment and a new patch adding up the alignment in aperture size. >> >> -- >> Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Mon, Jun 22, 2015 at 1:04 PM, Chris Wilson wrote: > On Mon, Jun 22, 2015 at 09:51:08PM +0200, Daniel Vetter wrote: >> On Mon, Jun 22, 2015 at 11:47:02AM -0700, Anuj Phogat wrote: >> > and use it to initialize the align variable in drm_intel_bo. >> > >> > In case of YF/YS tiled buffers libdrm need not know about the tiling >> > format because these buffers don't have hardware support to be tiled >> > or detiled through a fenced region. But, libdrm still need to know >> > about buffer alignment restrictions because kernel uses it when >> > resolving the relocation. >> > >> > Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers. >> > So, use the passed alignment value in this function. Note that we continue >> > ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow >> > the previous behavior. >> > >> > V2: Add a condition to avoid allocation from cache. (Ben) >> >> This will hurt badly since some programs love to cycle through textures. >> You can still allocate from the cache, you only need to update the >> alignement constraint. The kernel will move the buffer on the next execbuf >> if it's misplaced. > > For llc, using fresh pages just puts memory and aperture pressure (plus > a small amount of interface pressure) on the system by allocating more bo. > > For !llc, it is far better to move an object in the GTT to match a > change in alignment than it is to allocate fresh pages (and deallocate > stale pages). Could you please explain this and point me to what you want to be changed in this patch? > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] Set alignment value in drm_intel_add_validate_buffer()
On Mon, Jun 22, 2015 at 12:49 PM, Daniel Vetter wrote: > On Mon, Jun 22, 2015 at 10:21:46AM -0700, Ben Widawsky wrote: >> On Fri, Jun 19, 2015 at 03:52:01PM -0700, Anuj Phogat wrote: >> > +Ben >> > >> > On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote: >> > > Signed-off-by: Anuj Phogat >> > > --- >> > > intel/intel_bufmgr_gem.c | 4 ++-- >> > > 1 file changed, 2 insertions(+), 2 deletions(-) >> > > >> > > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c >> > > index 51d87ae..92701a5 100644 >> > > --- a/intel/intel_bufmgr_gem.c >> > > +++ b/intel/intel_bufmgr_gem.c >> > > @@ -459,7 +459,7 @@ drm_intel_add_validate_buffer(drm_intel_bo *bo) >> > > bufmgr_gem->exec_objects[index].handle = bo_gem->gem_handle; >> > > bufmgr_gem->exec_objects[index].relocation_count = >> > > bo_gem->reloc_count; >> > > bufmgr_gem->exec_objects[index].relocs_ptr = (uintptr_t) >> > > bo_gem->relocs; >> > > - bufmgr_gem->exec_objects[index].alignment = 0; >> > > + bufmgr_gem->exec_objects[index].alignment = bo->align; >> > > bufmgr_gem->exec_objects[index].offset = 0; >> > > bufmgr_gem->exec_bos[index] = bo; >> > > bufmgr_gem->exec_count++; >> >> I'm a bit hesitant about this hunk. We're never going to use this from a mesa >> that supports Yf/Ys - and going this path wouldn't be expected. Maybe add a >> warning if bo->align? (From your other patch I don't think it can ever >> happen, >> but just to future proof it. >> >> > > @@ -501,7 +501,7 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int >> > > need_fence) >> > > bufmgr_gem->exec2_objects[index].handle = bo_gem->gem_handle; >> > > bufmgr_gem->exec2_objects[index].relocation_count = >> > > bo_gem->reloc_count; >> > > bufmgr_gem->exec2_objects[index].relocs_ptr = >> > > (uintptr_t)bo_gem->relocs; >> > > - bufmgr_gem->exec2_objects[index].alignment = 0; >> > > + bufmgr_gem->exec2_objects[index].alignment = bo->align; >> > > bufmgr_gem->exec2_objects[index].offset = 0; >> > > bufmgr_gem->exec_bos[index] = bo; >> > > bufmgr_gem->exec2_objects[index].flags = 0; >> >> I was about to argue this should be part of patch 1, but nope, it should be a >> separate patch :-) >> >> I started digging into whether we have a reasonable way to determine if a bo >> alignment failed, and fall back to a softer restriction. It didn't seem >> doable >> with the current interfaces, but it's something to think about. > > On gen2/3 we have a lot more severe alignment problems and there the only > thing we've done is to take worst-case space loss for alignment into > account for the execbuf space estimation. But if that failed (and it did > every now and then) userspace just died. I don't think we need any of this > for new tiling layouts since they're all uniformly using a 64kb alignment. > The kernel should be able to pack this very well. Daniel, I don't know much about how kernel is handling the alignment constraints for new tiling layouts during relocation. I'm here mostly relying on the advice from kernel guys. These two patches are based on your comment on an earlier patch on intel-gfx: "[PATCH 4/5] Align YS tile base address to 64KB" Even if the kernel is already packing the new tiling layouts correctly, these patches are passing some valid alignment value in place of always zero. Isn't it a harmless change? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
and use it to initialize the align variable in drm_intel_bo.
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function. Note that we continue
ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
the previous behavior.
V2: Add a condition to avoid allocation from cache. (Ben)
Signed-off-by: Anuj Phogat
Cc: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 60c06fc..60f494e 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -660,7 +660,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
unsigned long size,
unsigned long flags,
uint32_t tiling_mode,
- unsigned long stride)
+ unsigned long stride,
+ unsigned int alignment)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
@@ -700,9 +701,14 @@ retry:
*/
bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
bucket->head.prev, head);
- DRMLISTDEL(&bo_gem->head);
- alloc_from_cache = true;
+ if (alignment > 0 && bo_gem->bo.align != alignment) {
+ alloc_from_cache = false;
+ } else {
+ alloc_from_cache = true;
+ DRMLISTDEL(&bo_gem->head);
+ }
} else {
+ assert(alignment == 0);
/* For non-render-target BOs (where we're probably
* going to map it first thing in order to fill it
* with data), check if the last BO in the cache is
@@ -759,6 +765,7 @@ retry:
return NULL;
}
bo_gem->bo.bufmgr = bufmgr;
+ bo_gem->bo.align = alignment;
bo_gem->tiling_mode = I915_TILING_NONE;
bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
@@ -802,7 +809,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
BO_ALLOC_FOR_RENDER,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0,
+ alignment);
}
static drm_intel_bo *
@@ -812,7 +820,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
unsigned int alignment)
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0, 0);
}
static drm_intel_bo *
@@ -864,7 +872,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
stride = 0;
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
- tiling, stride);
+ tiling, stride, 0);
}
static drm_intel_bo *
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Mon, Jun 22, 2015 at 10:01 AM, Ben Widawsky wrote:
> On Fri, Jun 19, 2015 at 03:50:44PM -0700, Anuj Phogat wrote:
>> +Ben.
>>
>> On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
>> > and use it to initialize the align variable in drm_intel_bo.
>> >
>> > In case of YF/YS tiled buffers libdrm need not know about the tiling
>> > format because these buffers don't have hardware support to be tiled
>> > or detiled through a fenced region. But, libdrm still need to know
>> > about buffer alignment restrictions because kernel uses it when
>> > resolving the relocation.
>> >
>> > Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
>> > So, use the passed alignment value in this function. Note that we continue
>> > ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
>> > the previous behavior.
>
> I think there is a problem here if you're getting the BO from the cache. If
> you
> allocate out of the cache, and the alignment is incorrect, I don't think
> anything will fix it for you.
>
Right. Thanks for catching this. I'll send out v2 with suggested changes.
>> >
>> > Cc: Kristian Høgsberg
>> > Cc: Damien Lespiau
>> > Cc: Daniel Vetter
>> > Signed-off-by: Anuj Phogat
>> > ---
>> > intel/intel_bufmgr_gem.c | 11 +++
>> > 1 file changed, 7 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> > index 5a67f53..51d87ae 100644
>> > --- a/intel/intel_bufmgr_gem.c
>> > +++ b/intel/intel_bufmgr_gem.c
>> > @@ -655,7 +655,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr
>> > *bufmgr,
>> > unsigned long size,
>> > unsigned long flags,
>> > uint32_t tiling_mode,
>> > - unsigned long stride)
>> > + unsigned long stride,
>> > + unsigned int alignment)
>> > {
>> > drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
>> > drm_intel_bo_gem *bo_gem;
>
> I think you need a check somewhere like:
> if (alignment &&
> bo_gem->bo.align != alignment)
> alloc_from_cache = false;
>
>> > @@ -754,6 +755,7 @@ retry:
>> > return NULL;
>> > }
>> > bo_gem->bo.bufmgr = bufmgr;
>> > + bo_gem->bo.align = alignment;
>> >
>> > bo_gem->tiling_mode = I915_TILING_NONE;
>> > bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
>> > @@ -797,7 +799,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr
>> > *bufmgr,
>> > {
>> > return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
>> >BO_ALLOC_FOR_RENDER,
>> > - I915_TILING_NONE, 0);
>> > + I915_TILING_NONE, 0,
>> > + alignment);
>> > }
>> >
>> > static drm_intel_bo *
>> > @@ -807,7 +810,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
>> >unsigned int alignment)
>> > {
>> > return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
>> > - I915_TILING_NONE, 0);
>> > + I915_TILING_NONE, 0, 0);
>> > }
>> >
>> > static drm_intel_bo *
>> > @@ -859,7 +862,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
>> > const char *name,
>> > stride = 0;
>> >
>> > return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
>> > - tiling, stride);
>> > + tiling, stride, 0);
>> > }
>> >
>> > static drm_intel_bo *
>> > --
>> > 2.3.4
>> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] Set alignment value in drm_intel_add_validate_buffer()
+Ben On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > intel/intel_bufmgr_gem.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c > index 51d87ae..92701a5 100644 > --- a/intel/intel_bufmgr_gem.c > +++ b/intel/intel_bufmgr_gem.c > @@ -459,7 +459,7 @@ drm_intel_add_validate_buffer(drm_intel_bo *bo) > bufmgr_gem->exec_objects[index].handle = bo_gem->gem_handle; > bufmgr_gem->exec_objects[index].relocation_count = > bo_gem->reloc_count; > bufmgr_gem->exec_objects[index].relocs_ptr = (uintptr_t) > bo_gem->relocs; > - bufmgr_gem->exec_objects[index].alignment = 0; > + bufmgr_gem->exec_objects[index].alignment = bo->align; > bufmgr_gem->exec_objects[index].offset = 0; > bufmgr_gem->exec_bos[index] = bo; > bufmgr_gem->exec_count++; > @@ -501,7 +501,7 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int > need_fence) > bufmgr_gem->exec2_objects[index].handle = bo_gem->gem_handle; > bufmgr_gem->exec2_objects[index].relocation_count = > bo_gem->reloc_count; > bufmgr_gem->exec2_objects[index].relocs_ptr = > (uintptr_t)bo_gem->relocs; > - bufmgr_gem->exec2_objects[index].alignment = 0; > + bufmgr_gem->exec2_objects[index].alignment = bo->align; > bufmgr_gem->exec2_objects[index].offset = 0; > bufmgr_gem->exec_bos[index] = bo; > bufmgr_gem->exec2_objects[index].flags = 0; > -- > 2.3.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
+Ben.
On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
> and use it to initialize the align variable in drm_intel_bo.
>
> In case of YF/YS tiled buffers libdrm need not know about the tiling
> format because these buffers don't have hardware support to be tiled
> or detiled through a fenced region. But, libdrm still need to know
> about buffer alignment restrictions because kernel uses it when
> resolving the relocation.
>
> Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
> So, use the passed alignment value in this function. Note that we continue
> ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
> the previous behavior.
>
> Cc: Kristian Høgsberg
> Cc: Damien Lespiau
> Cc: Daniel Vetter
> Signed-off-by: Anuj Phogat
> ---
> intel/intel_bufmgr_gem.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 5a67f53..51d87ae 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -655,7 +655,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
> unsigned long size,
> unsigned long flags,
> uint32_t tiling_mode,
> - unsigned long stride)
> + unsigned long stride,
> + unsigned int alignment)
> {
> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
> drm_intel_bo_gem *bo_gem;
> @@ -754,6 +755,7 @@ retry:
> return NULL;
> }
> bo_gem->bo.bufmgr = bufmgr;
> + bo_gem->bo.align = alignment;
>
> bo_gem->tiling_mode = I915_TILING_NONE;
> bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
> @@ -797,7 +799,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr
> *bufmgr,
> {
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
>BO_ALLOC_FOR_RENDER,
> - I915_TILING_NONE, 0);
> + I915_TILING_NONE, 0,
> + alignment);
> }
>
> static drm_intel_bo *
> @@ -807,7 +810,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
>unsigned int alignment)
> {
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
> - I915_TILING_NONE, 0);
> + I915_TILING_NONE, 0, 0);
> }
>
> static drm_intel_bo *
> @@ -859,7 +862,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
> const char *name,
> stride = 0;
>
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
> - tiling, stride);
> + tiling, stride, 0);
> }
>
> static drm_intel_bo *
> --
> 2.3.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Wed, Jun 10, 2015 at 1:47 AM, Damien Lespiau wrote: > On Tue, Jun 09, 2015 at 02:59:33PM -0700, Anuj Phogat wrote: >> This patch is on the list for 8 weeks now. Please take a look so I can push >> it upstream. > > Could I suggest you nominate a mesa team member working on SKL as well? > that would be the ideal match I believe. I will request someone in Mesa time to take a look. But, I still expect "looks fine/incorrect", "acked/nacked", "I don't know this code" comments by people who reviewed the v1. +Ben: Since he's reviewing my mesa patch: "i965/gen9: Allocate YF/YS tiled buffer objects" > > -- > Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] Set alignment value in drm_intel_add_validate_buffer()
On Wed, May 20, 2015 at 2:01 PM, Anuj Phogat wrote: > On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote: >> Signed-off-by: Anuj Phogat >> --- >> intel/intel_bufmgr_gem.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c >> index 51d87ae..92701a5 100644 >> --- a/intel/intel_bufmgr_gem.c >> +++ b/intel/intel_bufmgr_gem.c >> @@ -459,7 +459,7 @@ drm_intel_add_validate_buffer(drm_intel_bo *bo) >> bufmgr_gem->exec_objects[index].handle = bo_gem->gem_handle; >> bufmgr_gem->exec_objects[index].relocation_count = >> bo_gem->reloc_count; >> bufmgr_gem->exec_objects[index].relocs_ptr = (uintptr_t) >> bo_gem->relocs; >> - bufmgr_gem->exec_objects[index].alignment = 0; >> + bufmgr_gem->exec_objects[index].alignment = bo->align; >> bufmgr_gem->exec_objects[index].offset = 0; >> bufmgr_gem->exec_bos[index] = bo; >> bufmgr_gem->exec_count++; >> @@ -501,7 +501,7 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int >> need_fence) >> bufmgr_gem->exec2_objects[index].handle = bo_gem->gem_handle; >> bufmgr_gem->exec2_objects[index].relocation_count = >> bo_gem->reloc_count; >> bufmgr_gem->exec2_objects[index].relocs_ptr = >> (uintptr_t)bo_gem->relocs; >> - bufmgr_gem->exec2_objects[index].alignment = 0; >> + bufmgr_gem->exec2_objects[index].alignment = bo->align; >> bufmgr_gem->exec2_objects[index].offset = 0; >> bufmgr_gem->exec_bos[index] = bo; >> bufmgr_gem->exec2_objects[index].flags = 0; >> -- >> 2.3.4 >> > Bump This patch is on the list for 8 weeks now. Please take a look so I can push it upstream. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Wed, May 20, 2015 at 2:01 PM, Anuj Phogat wrote:
> On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
>> and use it to initialize the align variable in drm_intel_bo.
>>
>> In case of YF/YS tiled buffers libdrm need not know about the tiling
>> format because these buffers don't have hardware support to be tiled
>> or detiled through a fenced region. But, libdrm still need to know
>> about buffer alignment restrictions because kernel uses it when
>> resolving the relocation.
>>
>> Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
>> So, use the passed alignment value in this function. Note that we continue
>> ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
>> the previous behavior.
>>
>> Cc: Kristian Høgsberg
>> Cc: Damien Lespiau
>> Cc: Daniel Vetter
>> Signed-off-by: Anuj Phogat
>> ---
>> intel/intel_bufmgr_gem.c | 11 +++
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> index 5a67f53..51d87ae 100644
>> --- a/intel/intel_bufmgr_gem.c
>> +++ b/intel/intel_bufmgr_gem.c
>> @@ -655,7 +655,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
>> unsigned long size,
>> unsigned long flags,
>> uint32_t tiling_mode,
>> - unsigned long stride)
>> + unsigned long stride,
>> + unsigned int alignment)
>> {
>> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
>> drm_intel_bo_gem *bo_gem;
>> @@ -754,6 +755,7 @@ retry:
>> return NULL;
>> }
>> bo_gem->bo.bufmgr = bufmgr;
>> + bo_gem->bo.align = alignment;
>>
>> bo_gem->tiling_mode = I915_TILING_NONE;
>> bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
>> @@ -797,7 +799,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr
>> *bufmgr,
>> {
>> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
>>BO_ALLOC_FOR_RENDER,
>> - I915_TILING_NONE, 0);
>> + I915_TILING_NONE, 0,
>> + alignment);
>> }
>>
>> static drm_intel_bo *
>> @@ -807,7 +810,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
>>unsigned int alignment)
>> {
>> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
>> - I915_TILING_NONE, 0);
>> + I915_TILING_NONE, 0, 0);
>> }
>>
>> static drm_intel_bo *
>> @@ -859,7 +862,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
>> const char *name,
>> stride = 0;
>>
>> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
>> - tiling, stride);
>> + tiling, stride, 0);
>> }
>>
>> static drm_intel_bo *
>> --
>> 2.3.4
>>
> Bump
This patch is on the list for 8 weeks now. Please take a look so I can push
it upstream.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] Set alignment value in drm_intel_add_validate_buffer()
On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote: > Signed-off-by: Anuj Phogat > --- > intel/intel_bufmgr_gem.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c > index 51d87ae..92701a5 100644 > --- a/intel/intel_bufmgr_gem.c > +++ b/intel/intel_bufmgr_gem.c > @@ -459,7 +459,7 @@ drm_intel_add_validate_buffer(drm_intel_bo *bo) > bufmgr_gem->exec_objects[index].handle = bo_gem->gem_handle; > bufmgr_gem->exec_objects[index].relocation_count = > bo_gem->reloc_count; > bufmgr_gem->exec_objects[index].relocs_ptr = (uintptr_t) > bo_gem->relocs; > - bufmgr_gem->exec_objects[index].alignment = 0; > + bufmgr_gem->exec_objects[index].alignment = bo->align; > bufmgr_gem->exec_objects[index].offset = 0; > bufmgr_gem->exec_bos[index] = bo; > bufmgr_gem->exec_count++; > @@ -501,7 +501,7 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int > need_fence) > bufmgr_gem->exec2_objects[index].handle = bo_gem->gem_handle; > bufmgr_gem->exec2_objects[index].relocation_count = > bo_gem->reloc_count; > bufmgr_gem->exec2_objects[index].relocs_ptr = > (uintptr_t)bo_gem->relocs; > - bufmgr_gem->exec2_objects[index].alignment = 0; > + bufmgr_gem->exec2_objects[index].alignment = bo->align; > bufmgr_gem->exec2_objects[index].offset = 0; > bufmgr_gem->exec_bos[index] = bo; > bufmgr_gem->exec2_objects[index].flags = 0; > -- > 2.3.4 > Bump ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
> and use it to initialize the align variable in drm_intel_bo.
>
> In case of YF/YS tiled buffers libdrm need not know about the tiling
> format because these buffers don't have hardware support to be tiled
> or detiled through a fenced region. But, libdrm still need to know
> about buffer alignment restrictions because kernel uses it when
> resolving the relocation.
>
> Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
> So, use the passed alignment value in this function. Note that we continue
> ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
> the previous behavior.
>
> Cc: Kristian Høgsberg
> Cc: Damien Lespiau
> Cc: Daniel Vetter
> Signed-off-by: Anuj Phogat
> ---
> intel/intel_bufmgr_gem.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 5a67f53..51d87ae 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -655,7 +655,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
> unsigned long size,
> unsigned long flags,
> uint32_t tiling_mode,
> - unsigned long stride)
> + unsigned long stride,
> + unsigned int alignment)
> {
> drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
> drm_intel_bo_gem *bo_gem;
> @@ -754,6 +755,7 @@ retry:
> return NULL;
> }
> bo_gem->bo.bufmgr = bufmgr;
> + bo_gem->bo.align = alignment;
>
> bo_gem->tiling_mode = I915_TILING_NONE;
> bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
> @@ -797,7 +799,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr
> *bufmgr,
> {
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
>BO_ALLOC_FOR_RENDER,
> - I915_TILING_NONE, 0);
> + I915_TILING_NONE, 0,
> + alignment);
> }
>
> static drm_intel_bo *
> @@ -807,7 +810,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
>unsigned int alignment)
> {
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
> - I915_TILING_NONE, 0);
> + I915_TILING_NONE, 0, 0);
> }
>
> static drm_intel_bo *
> @@ -859,7 +862,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
> const char *name,
> stride = 0;
>
> return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
> - tiling, stride);
> + tiling, stride, 0);
> }
>
> static drm_intel_bo *
> --
> 2.3.4
>
Bump
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] i965/gen9: Pass alignment as function parameter in drm_intel_gem_bo_alloc_internal()
and use it to initialize the align variable in drm_intel_bo.
In case of YF/YS tiled buffers libdrm need not know about the tiling
format because these buffers don't have hardware support to be tiled
or detiled through a fenced region. But, libdrm still need to know
about buffer alignment restrictions because kernel uses it when
resolving the relocation.
Mesa uses drm_intel_gem_bo_alloc_for_render() to allocate Yf/Ys buffers.
So, use the passed alignment value in this function. Note that we continue
ignoring the alignment value passed to drm_intel_gem_bo_alloc() to follow
the previous behavior.
Cc: Kristian Høgsberg
Cc: Damien Lespiau
Cc: Daniel Vetter
Signed-off-by: Anuj Phogat
---
intel/intel_bufmgr_gem.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5a67f53..51d87ae 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -655,7 +655,8 @@ drm_intel_gem_bo_alloc_internal(drm_intel_bufmgr *bufmgr,
unsigned long size,
unsigned long flags,
uint32_t tiling_mode,
- unsigned long stride)
+ unsigned long stride,
+ unsigned int alignment)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
@@ -754,6 +755,7 @@ retry:
return NULL;
}
bo_gem->bo.bufmgr = bufmgr;
+ bo_gem->bo.align = alignment;
bo_gem->tiling_mode = I915_TILING_NONE;
bo_gem->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
@@ -797,7 +799,8 @@ drm_intel_gem_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size,
BO_ALLOC_FOR_RENDER,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0,
+ alignment);
}
static drm_intel_bo *
@@ -807,7 +810,7 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
unsigned int alignment)
{
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, 0,
- I915_TILING_NONE, 0);
+ I915_TILING_NONE, 0, 0);
}
static drm_intel_bo *
@@ -859,7 +862,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
stride = 0;
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
- tiling, stride);
+ tiling, stride, 0);
}
static drm_intel_bo *
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] Set alignment value in drm_intel_add_validate_buffer()
Signed-off-by: Anuj Phogat --- intel/intel_bufmgr_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 51d87ae..92701a5 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -459,7 +459,7 @@ drm_intel_add_validate_buffer(drm_intel_bo *bo) bufmgr_gem->exec_objects[index].handle = bo_gem->gem_handle; bufmgr_gem->exec_objects[index].relocation_count = bo_gem->reloc_count; bufmgr_gem->exec_objects[index].relocs_ptr = (uintptr_t) bo_gem->relocs; - bufmgr_gem->exec_objects[index].alignment = 0; + bufmgr_gem->exec_objects[index].alignment = bo->align; bufmgr_gem->exec_objects[index].offset = 0; bufmgr_gem->exec_bos[index] = bo; bufmgr_gem->exec_count++; @@ -501,7 +501,7 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int need_fence) bufmgr_gem->exec2_objects[index].handle = bo_gem->gem_handle; bufmgr_gem->exec2_objects[index].relocation_count = bo_gem->reloc_count; bufmgr_gem->exec2_objects[index].relocs_ptr = (uintptr_t)bo_gem->relocs; - bufmgr_gem->exec2_objects[index].alignment = 0; + bufmgr_gem->exec2_objects[index].alignment = bo->align; bufmgr_gem->exec2_objects[index].offset = 0; bufmgr_gem->exec_bos[index] = bo; bufmgr_gem->exec2_objects[index].flags = 0; -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] Align YS tile base address to 64KB
On Tue, Mar 31, 2015 at 11:11 PM, Daniel Vetter wrote: > On Tue, Mar 31, 2015 at 06:57:07PM +0100, Damien Lespiau wrote: >> On Tue, Mar 31, 2015 at 10:49:22AM -0700, Anuj Phogat wrote: >> > On Tue, Mar 31, 2015 at 7:26 AM, Damien Lespiau >> > wrote: >> > > On Mon, Mar 30, 2015 at 02:00:07PM -0700, Anuj Phogat wrote: >> > >> Signed-off-by: Anuj Phogat >> > >> --- >> > >> intel/intel_bufmgr_gem.c | 7 ++- >> > >> 1 file changed, 6 insertions(+), 1 deletion(-) >> > >> >> > >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c >> > >> index 7c50e26..775a9f9 100644 >> > >> --- a/intel/intel_bufmgr_gem.c >> > >> +++ b/intel/intel_bufmgr_gem.c >> > >> @@ -289,8 +289,13 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem >> > >> *bufmgr_gem, unsigned long size, >> > >> if (*tiling_mode == I915_TILING_NONE) >> > >> return size; >> > >> >> > >> + /* Tiled surface base addresses must be tile aligned (64KB aligned >> > >> + * for TileYS, 4KB aligned for all other tile modes). >> > >> + */ >> > >> + if (*tiling_mode == I915_TILING_YS) >> > >> + return ROUND_UP_TO(size, 64 * 1024); >> > >> /* 965+ just need multiples of page size for tiling */ >> > >> - if (bufmgr_gem->gen >= 4) >> > >> + else if (bufmgr_gem->gen >= 4) >> > >> return ROUND_UP_TO(size, 4096); >> > > >> > > I'm confused. You're saying you want to align the address of those >> > > buffers to 64k, but here we're talking about the object size. At the >> > > moment, the kernel places buffers in the address space and it was chosen >> > > that the kernel didn't need to know about those tiling formats. So we >> > > need something else if that constraint is indeed true (could you tell >> > > us the source for this assertion? privately if needed). >> > > >> > This comment is invalid here. It was meant for surface state in Mesa. >> > I'll remove it. >> >> Don't you have the exact same problem? how does the kernel know about >> this alignment constraint when resolving the relocation? > > struct drm_i915_gem_exec_object2.alignment goes back to some gen2/3 design > ideas that (afaik at least) have never been used really but survived until > now. Fancy how we can reuse that 7 generations later ;-) > > And at least on a quick readthrough the code is all still functional too. Yes, I'm planning to make use of it and pass alignment value for Yf/Ys from Mesa. Thanks. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] i965/skl: Add macros for Yf/Ys tiling formats
On Tue, Mar 31, 2015 at 6:17 AM, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 02:00:04PM -0700, Anuj Phogat wrote:
>> Signed-off-by: Anuj Phogat
>> ---
>> include/drm/i915_drm.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index ded43b1..a6c167c 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -842,6 +842,8 @@ struct drm_i915_gem_caching {
>> #define I915_TILING_NONE 0
>> #define I915_TILING_X1
>> #define I915_TILING_Y2
>> +#define I915_TILING_YF 3
>> +#define I915_TILING_YS 4
>
> This is based on an old version of the Yf/Ys tiling patches which have not
> been merged, so nack.
>
Following your IRC chat with Kristian, and my offline discussion with
him, I will move the tile size computation (using width, height, cpp) for
Yf/Ys in to mesa. Then these definitions are not required in here.
> When you update the kernel headers in libdrm, _always_ use
>
> $ make headers_install
>
> from kernel sources and then copy over the headers unchanged to libdrm.
> Never handedit i915_drm.h.
OK. Thanks for the information.
> -Daniel
>
>>
>> #define I915_BIT_6_SWIZZLE_NONE 0
>> #define I915_BIT_6_SWIZZLE_9 1
>> --
>> 2.3.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] build: Bump the version to 2.4.61
On Tue, Mar 31, 2015 at 7:28 AM, Damien Lespiau wrote: > On Mon, Mar 30, 2015 at 02:00:08PM -0700, Anuj Phogat wrote: >> This is required due to new macros added to i915_drm.h. >> These macros are used by i965 driver. >> >> Signed-off-by: Anuj Phogat >> --- > > Hi, > > Bumping the libdrm number is done when releasing, so we can't quite take > patches like this unless we're doing a release just after applying them. > Usually the person doing the release bumps the version number at the > same time. OK. > > -- > Damien > >> configure.ac | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/configure.ac b/configure.ac >> index 155d577..17c0e71 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -20,7 +20,7 @@ >> >> AC_PREREQ([2.63]) >> AC_INIT([libdrm], >> -[2.4.60], >> +[2.4.61], >> [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI], >> [libdrm]) >> >> -- >> 2.3.4 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] Align YS tile base address to 64KB
On Tue, Mar 31, 2015 at 7:26 AM, Damien Lespiau wrote: > On Mon, Mar 30, 2015 at 02:00:07PM -0700, Anuj Phogat wrote: >> Signed-off-by: Anuj Phogat >> --- >> intel/intel_bufmgr_gem.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c >> index 7c50e26..775a9f9 100644 >> --- a/intel/intel_bufmgr_gem.c >> +++ b/intel/intel_bufmgr_gem.c >> @@ -289,8 +289,13 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem >> *bufmgr_gem, unsigned long size, >> if (*tiling_mode == I915_TILING_NONE) >> return size; >> >> + /* Tiled surface base addresses must be tile aligned (64KB aligned >> + * for TileYS, 4KB aligned for all other tile modes). >> + */ >> + if (*tiling_mode == I915_TILING_YS) >> + return ROUND_UP_TO(size, 64 * 1024); >> /* 965+ just need multiples of page size for tiling */ >> - if (bufmgr_gem->gen >= 4) >> + else if (bufmgr_gem->gen >= 4) >> return ROUND_UP_TO(size, 4096); > > I'm confused. You're saying you want to align the address of those > buffers to 64k, but here we're talking about the object size. At the > moment, the kernel places buffers in the address space and it was chosen > that the kernel didn't need to know about those tiling formats. So we > need something else if that constraint is indeed true (could you tell > us the source for this assertion? privately if needed). > This comment is invalid here. It was meant for surface state in Mesa. I'll remove it. > Thanks, > > -- > Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] i965/skl: Move tile_width computations out of drm_intel_gem_bo_tile_pitch
This will be utilized by next patch in this series.
Signed-off-by: Anuj Phogat
---
intel/intel_bufmgr_gem.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5a67f53..af44ba5 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -324,9 +324,9 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem
*bufmgr_gem, unsigned long size,
*/
static unsigned long
drm_intel_gem_bo_tile_pitch(drm_intel_bufmgr_gem *bufmgr_gem,
- unsigned long pitch, uint32_t *tiling_mode)
+ unsigned long pitch, unsigned long tile_width,
+ uint32_t *tiling_mode)
{
- unsigned long tile_width;
unsigned long i;
/* If untiled, then just align it so that we can do rendering
@@ -335,13 +335,6 @@ drm_intel_gem_bo_tile_pitch(drm_intel_bufmgr_gem
*bufmgr_gem,
if (*tiling_mode == I915_TILING_NONE)
return ALIGN(pitch, 64);
- if (*tiling_mode == I915_TILING_X
- || (IS_915(bufmgr_gem->pci_device)
- && *tiling_mode == I915_TILING_Y))
- tile_width = 512;
- else
- tile_width = 128;
-
/* 965 is flexible */
if (bufmgr_gem->gen >= 4)
return ROUND_UP_TO(pitch, tile_width);
@@ -816,7 +809,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long *pitch, unsigned long flags)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bufmgr;
- unsigned long size, stride;
+ unsigned long size, stride, tile_width;
uint32_t tiling;
do {
@@ -842,14 +835,18 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
height_alignment = 16;
else if (tiling == I915_TILING_X
|| (IS_915(bufmgr_gem->pci_device)
- && tiling == I915_TILING_Y))
+ && tiling == I915_TILING_Y)) {
height_alignment = 8;
- else if (tiling == I915_TILING_Y)
+ tile_width = 512;
+ } else if (tiling == I915_TILING_Y)
height_alignment = 32;
+ tile_width = 128;
+ }
aligned_y = ALIGN(y, height_alignment);
stride = x * cpp;
- stride = drm_intel_gem_bo_tile_pitch(bufmgr_gem, stride,
tiling_mode);
+ stride = drm_intel_gem_bo_tile_pitch(bufmgr_gem, stride,
+tile_width, tiling_mode);
size = stride * aligned_y;
size = drm_intel_gem_bo_tile_size(bufmgr_gem, size,
tiling_mode);
} while (*tiling_mode != tiling);
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] i965/skl: Add macros for Yf/Ys tiling formats
Signed-off-by: Anuj Phogat
---
include/drm/i915_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..a6c167c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -842,6 +842,8 @@ struct drm_i915_gem_caching {
#define I915_TILING_NONE 0
#define I915_TILING_X 1
#define I915_TILING_Y 2
+#define I915_TILING_YF 3
+#define I915_TILING_YS 4
#define I915_BIT_6_SWIZZLE_NONE0
#define I915_BIT_6_SWIZZLE_9 1
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] i965/skl: Set tile width and height for YF/YS tiling
I'm still passing tiling=I915_TILING_Y in drm_intel_gem_bo_alloc_internal()
in case of YF/YS tiling. Passing tiling=I915_TILING_{YF,YS} causes bo
allocation failure. Any advice what's the right thing to do here?
Signed-off-by: Anuj Phogat
---
intel/intel_bufmgr_gem.c | 49 +++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index af44ba5..7c50e26 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -803,6 +803,39 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
I915_TILING_NONE, 0);
}
+/* This function does tile height computations valid only for Yf/Ys tiled
+ * surfaces.
+ */
+static unsigned
+drm_intel_gem_tile_height(unsigned bpp, uint32_t tiling)
+{
+ unsigned tile_height;
+ assert(tiling == I915_TILING_YF || tiling == I915_TILING_YS);
+
+ switch (bpp) {
+ case 8:
+ tile_height = 64;
+ break;
+ case 16:
+ case 32:
+ tile_height = 32;
+ break;
+ case 64:
+ case 128:
+ tile_height = 16;
+ break;
+ default:
+ printf("Invalid bits per pixel in %s: bpp = %d\n",
+ __FUNCTION__, bpp);
+ return 0;
+ }
+
+ if (tiling == I915_TILING_YS)
+ tile_height *= 4;
+
+ return tile_height;
+}
+
static drm_intel_bo *
drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
@@ -838,7 +871,15 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
&& tiling == I915_TILING_Y)) {
height_alignment = 8;
tile_width = 512;
- } else if (tiling == I915_TILING_Y)
+ } else if (tiling == I915_TILING_YF ||
+ tiling == I915_TILING_YS) {
+ unsigned bpp = cpp * 8;
+ unsigned aspect_ratio =
+ (bpp == 16 || bpp == 64) ? 2 : 1;
+ height_alignment =
+ drm_intel_gem_tile_height(bpp, tiling);
+ tile_width = height_alignment * cpp * aspect_ratio;
+ } else if (tiling == I915_TILING_Y){
height_alignment = 32;
tile_width = 128;
}
@@ -855,6 +896,12 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
if (tiling == I915_TILING_NONE)
stride = 0;
+ /* Use I915_TILING_Y in drm_intel_gem_bo_alloc_internal() in case of
+* YF/YS tiling.
+*/
+ tiling = (tiling == I915_TILING_YF || tiling == I915_TILING_YS) ?
+ I915_TILING_Y : tiling;
+
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
tiling, stride);
}
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] build: Bump the version to 2.4.61
This is required due to new macros added to i915_drm.h. These macros are used by i965 driver. Signed-off-by: Anuj Phogat --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 155d577..17c0e71 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,7 @@ AC_PREREQ([2.63]) AC_INIT([libdrm], -[2.4.60], +[2.4.61], [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI], [libdrm]) -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] i965/skl: Add YF/YS tiling support
Series is available at: https://github.com/aphogat/drm.git, branch: tiling-yf-ys Anuj Phogat (5): i965/skl: Add macros for Yf/Ys tiling formats i965/skl: Move tile_width computations out of drm_intel_gem_bo_tile_pitch i965/skl: Set tile width and height for YF/YS tiling Align YS tile base address to 64KB build: Bump the version to 2.4.61 configure.ac | 2 +- include/drm/i915_drm.h | 2 ++ intel/intel_bufmgr_gem.c | 77 +++- 3 files changed, 66 insertions(+), 15 deletions(-) -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] Align YS tile base address to 64KB
Signed-off-by: Anuj Phogat --- intel/intel_bufmgr_gem.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 7c50e26..775a9f9 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -289,8 +289,13 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem *bufmgr_gem, unsigned long size, if (*tiling_mode == I915_TILING_NONE) return size; + /* Tiled surface base addresses must be tile aligned (64KB aligned +* for TileYS, 4KB aligned for all other tile modes). +*/ + if (*tiling_mode == I915_TILING_YS) + return ROUND_UP_TO(size, 64 * 1024); /* 965+ just need multiples of page size for tiling */ - if (bufmgr_gem->gen >= 4) + else if (bufmgr_gem->gen >= 4) return ROUND_UP_TO(size, 4096); /* Older chips need powers of two, of at least 512k or 1M */ -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Fix a case when mapping large texture fails
On Mon 27 Feb 2012 11:45:46 AM PST, Anuj Phogat wrote:
> This patch handles a case when mapping a large texture fails
> in drm_intel_gem_bo_map_gtt(). These changes avoid assertion
> failure later in the driver as reported in following bugs:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=44970
> https://bugs.freedesktop.org/show_bug.cgi?id=46303
>
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 26 ---
> src/mesa/drivers/dri/intel/intel_regions.c |7 -
> 2 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> index 5290da4..507702a 100644
> --- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
> @@ -702,15 +702,20 @@ intel_miptree_map_gtt(struct intel_context *intel,
> y /= bh;
>
> base = intel_region_map(intel, mt->region, map->mode);
> - /* Note that in the case of cube maps, the caller must have passed the
> slice
> -* number referencing the face.
> -*/
> - intel_miptree_get_image_offset(mt, level, 0, slice, &image_x, &image_y);
> - x += image_x;
> - y += image_y;
>
> - map->stride = mt->region->pitch * mt->cpp;
> - map->ptr = base + y * map->stride + x * mt->cpp;
> + if (base == NULL)
> + map->ptr = NULL;
> + else {
> + /* Note that in the case of cube maps, the caller must have passed the
> + * slice number referencing the face.
> + */
> + intel_miptree_get_image_offset(mt, level, 0, slice, &image_x,
> &image_y);
> + x += image_x;
> + y += image_y;
> +
> + map->stride = mt->region->pitch * mt->cpp;
> + map->ptr = base + y * map->stride + x * mt->cpp;
> + }
>
> DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __FUNCTION__,
> map->x, map->y, map->w, map->h,
> @@ -1063,6 +1068,11 @@ intel_miptree_map(struct intel_context *intel,
>
> *out_ptr = map->ptr;
> *out_stride = map->stride;
> +
> + if (map->ptr == NULL) {
> + mt->level[level].slice[slice].map = NULL;
> + free(map);
> + }
> }
>
> void
> diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
> b/src/mesa/drivers/dri/intel/intel_regions.c
> index bc83649..982d6cb 100644
> --- a/src/mesa/drivers/dri/intel/intel_regions.c
> +++ b/src/mesa/drivers/dri/intel/intel_regions.c
> @@ -124,7 +124,7 @@ intel_region_map(struct intel_context *intel, struct
> intel_region *region,
> */
>
> _DBG("%s %p\n", __FUNCTION__, region);
> - if (!region->map_refcount++) {
> + if (!region->map_refcount) {
>intel_flush(&intel->ctx);
>
>if (region->tiling != I915_TILING_NONE)
> @@ -133,7 +133,10 @@ intel_region_map(struct intel_context *intel, struct
> intel_region *region,
>drm_intel_bo_map(region->bo, true);
>
>region->map = region->bo->virtual;
> - ++intel->num_mapped_regions;
> + if (region->map) {
> + ++intel->num_mapped_regions;
> + region->map_refcount++;
> + }
> }
>
> return region->map;
Any comments on this patch?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object
This patch sets an upper limit on the size of buffer object which can be
mapped safely. Following bugs reported segmentation fault / assertion
failure with large textures:
https://bugs.freedesktop.org/show_bug.cgi?id=44970
https://bugs.freedesktop.org/show_bug.cgi?id=46303
This patch along with another patch which I posted on mesa-dev
(intel: Fix a case when mapping large texture fails) resolve
above mentioned bugs. Recently posted piglit test case (large-textures)
also passes with these patches.
Signed-off-by: Anuj Phogat
---
This fix doesn't limit developers to create very large texture but it
restricts them to map it. I am not very confident about this patch and
setting 128 MB as the upper limit on size of buffer object. So, please
provide your views.
Chris Wilson's views on this issue:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg08585.html
intel/intel_bufmgr_gem.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 0f33b71..8b05de9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1191,6 +1191,17 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
pthread_mutex_lock(&bufmgr_gem->lock);
+ /* Set am upper limit on the size of buffer which can be mapped
+ safely
+*/
+ if (bo->size > 128 * 1024 * 1024) {
+ DBG("%s:%d: Reached buffer map limit.\n",
+ __FILE__, __LINE__);
+ bo->virtual = NULL;
+ pthread_mutex_unlock(&bufmgr_gem->lock);
+ return -1;
+ }
+
if (bo_gem->map_count++ == 0)
drm_intel_gem_bo_open_vma(bufmgr_gem, bo_gem);
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Fix a case when mapping large texture fails
This patch handles a case when mapping a large texture fails
in drm_intel_gem_bo_map_gtt(). These changes avoid assertion
failure later in the driver as reported in following bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=44970
https://bugs.freedesktop.org/show_bug.cgi?id=46303
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 26 ---
src/mesa/drivers/dri/intel/intel_regions.c |7 -
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 5290da4..507702a 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -702,15 +702,20 @@ intel_miptree_map_gtt(struct intel_context *intel,
y /= bh;
base = intel_region_map(intel, mt->region, map->mode);
- /* Note that in the case of cube maps, the caller must have passed the slice
-* number referencing the face.
-*/
- intel_miptree_get_image_offset(mt, level, 0, slice, &image_x, &image_y);
- x += image_x;
- y += image_y;
- map->stride = mt->region->pitch * mt->cpp;
- map->ptr = base + y * map->stride + x * mt->cpp;
+ if (base == NULL)
+ map->ptr = NULL;
+ else {
+ /* Note that in the case of cube maps, the caller must have passed the
+ * slice number referencing the face.
+ */
+ intel_miptree_get_image_offset(mt, level, 0, slice, &image_x, &image_y);
+ x += image_x;
+ y += image_y;
+
+ map->stride = mt->region->pitch * mt->cpp;
+ map->ptr = base + y * map->stride + x * mt->cpp;
+ }
DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __FUNCTION__,
map->x, map->y, map->w, map->h,
@@ -1063,6 +1068,11 @@ intel_miptree_map(struct intel_context *intel,
*out_ptr = map->ptr;
*out_stride = map->stride;
+
+ if (map->ptr == NULL) {
+ mt->level[level].slice[slice].map = NULL;
+ free(map);
+ }
}
void
diff --git a/src/mesa/drivers/dri/intel/intel_regions.c
b/src/mesa/drivers/dri/intel/intel_regions.c
index bc83649..982d6cb 100644
--- a/src/mesa/drivers/dri/intel/intel_regions.c
+++ b/src/mesa/drivers/dri/intel/intel_regions.c
@@ -124,7 +124,7 @@ intel_region_map(struct intel_context *intel, struct
intel_region *region,
*/
_DBG("%s %p\n", __FUNCTION__, region);
- if (!region->map_refcount++) {
+ if (!region->map_refcount) {
intel_flush(&intel->ctx);
if (region->tiling != I915_TILING_NONE)
@@ -133,7 +133,10 @@ intel_region_map(struct intel_context *intel, struct
intel_region *region,
drm_intel_bo_map(region->bo, true);
region->map = region->bo->virtual;
- ++intel->num_mapped_regions;
+ if (region->map) {
+ ++intel->num_mapped_regions;
+region->map_refcount++;
+ }
}
return region->map;
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915 fails to prepare buffer map with large textures
>
> > >> width, height parameter of glTexImage2D() includes: texture image
>> > >> width + 2 * border (if any). So when doing the texture size check
>> > >> in _mesa_test_proxy_teximage() width and height should not exceed
>> > >> maximum supported size for target texture type.
>> > >> i.e. 1<< (ctx->Const.MaxTextureLevels - 1)
>> > >>
>> > >> This patch fixes Intel oglconform test case: max_values
>> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
>> > >>
>> > >> Note: This is a candidate for mesa 8.0 branch.
>> > >>
>> > >> Signed-off-by: Anuj Phogat
>> > >> ---
>> > >> src/mesa/main/teximage.c | 22 +++---
>> > >> 1 files changed, 11 insertions(+), 11 deletions(-)
>> > >>
>> > >> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> > >> index d11425d..018aca0 100644
>> > >> --- a/src/mesa/main/teximage.c
>> > >> +++ b/src/mesa/main/teximage.c
>> > >> @@ -1179,7 +1179,7 @@ _mesa_test_proxy_teximage(struct gl_context
>> > >> *ctx, GLenum target, GLint level,
>> > >> switch (target) {
>> > >> case GL_PROXY_TEXTURE_1D:
>> > >> maxSize = 1<< (ctx->Const.MaxTextureLevels - 1);
>> > >> - if (width< 2 * border || width> 2 + maxSize)
>> > >> + if (width< 2 * border || width> maxSize)
>> > >
>> > > Anuj,
>> > >
>> > > I may be missing something, but I'm still unsure about this,
>> > > because this will create problems for drivers that do support
>> > > borders.
>> >
>> > AFAIK, the only desktop graphics hardware that ever supported borders
>> > is
>> > NVIDIA. Their driver follows the convention (width + 2 * border) <
>> > maxSize, and their driver advertises a maximum size of 2^n. I tried
>> > creating a proxy texture that was the full 2^n plus a border on their
>> > closed-source Linux driver, and it was rejected. A proxy texture
>> > 2^n-2
>> > plus a border was accepted.
>> >
>> > Based on that, I believe this patch is correct.
>>
>> Fair enough. Sounds good to me then!
>
>
> patch in commit 15986d21ebaaeedb234b066edba5cf7f6ea87a3c made the intel
> oglconform test to pass. But the errors reported in oglconform failure stays
> unfixed. This is confirmed by a piglit test case I developed to reproduce the
> errors. Test case (validate-texture-size) is posted on piglit mailing list
> for review.
>
> Driver throws assertion failure or segfaults with large textures even much
> below the maximum supported size.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=44970
>
> Further debugging shows an error while preparing buffer map in
intel_region_map( ) =>
drm_intel_gem_bo_map_gtt( ) => drmIoctl() returns -1
"Error preparing buffer map"
strerror(errno) = 0x4dd6c234
bo_gem->gtt_virtual=0x0
region->map = 0x0
dstMap = 0x0 in store_texsubimage()
which results in error "GL_OUT_OF_MEMORY in glTexSubImage" .
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
