All of lore.kernel.org
 help / color / mirror / Atom feed
* [CI 0/2] Reviewed perf cleanups
@ 2018-08-13  8:02 Tvrtko Ursulin
  2018-08-13  8:02 ` [CI 1/2] drm/i915/perf: simplify configure all context function Tvrtko Ursulin
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-13  8:02 UTC (permalink / raw)
  To: Intel-gfx

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Two reviewed simple cleanup patches, extracted from dynamic SSEU series.

Lionel Landwerlin (2):
  drm/i915/perf: simplify configure all context function
  drm/i915/perf: reuse intel_lrc ctx regs macro

 drivers/gpu/drm/i915/i915_perf.c | 45 ++++++++++++++------------------
 1 file changed, 20 insertions(+), 25 deletions(-)

-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [CI 1/2] drm/i915/perf: simplify configure all context function
  2018-08-13  8:02 [CI 0/2] Reviewed perf cleanups Tvrtko Ursulin
@ 2018-08-13  8:02 ` Tvrtko Ursulin
  2018-08-13  8:02 ` [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro Tvrtko Ursulin
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-13  8:02 UTC (permalink / raw)
  To: Intel-gfx

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

We don't need any special treatment on error so just return as soon as
possible.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_perf.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0376338d1f8d..49597cf31707 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1819,7 +1819,7 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
 	/* Switch away from any user context. */
 	ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
 	if (ret)
-		goto out;
+		return ret;
 
 	/*
 	 * The OA register config is setup through the context image. This image
@@ -1838,7 +1838,7 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
 				     wait_flags,
 				     MAX_SCHEDULE_TIMEOUT);
 	if (ret)
-		goto out;
+		return ret;
 
 	/* Update all contexts now that we've stalled the submission. */
 	list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1850,10 +1850,8 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
 			continue;
 
 		regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
-		if (IS_ERR(regs)) {
-			ret = PTR_ERR(regs);
-			goto out;
-		}
+		if (IS_ERR(regs))
+			return PTR_ERR(regs);
 
 		ce->state->obj->mm.dirty = true;
 		regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1863,7 +1861,6 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
 		i915_gem_object_unpin_map(ce->state->obj);
 	}
 
- out:
 	return ret;
 }
 
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-13  8:02 [CI 0/2] Reviewed perf cleanups Tvrtko Ursulin
  2018-08-13  8:02 ` [CI 1/2] drm/i915/perf: simplify configure all context function Tvrtko Ursulin
@ 2018-08-13  8:02 ` Tvrtko Ursulin
  2018-08-13  8:16   ` Chris Wilson
  2018-08-13  8:33 ` ✓ Fi.CI.BAT: success for Reviewed perf cleanups Patchwork
  2018-08-13 10:00 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 1 reply; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-13  8:02 UTC (permalink / raw)
  To: Intel-gfx

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Abstract the context image access a bit.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 49597cf31707..ccb20230df2c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
 #include "i915_oa_cflgt3.h"
 #include "i915_oa_cnl.h"
 #include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
 
 /* HW requires this to be a power of two, between 128k and 16M, though driver
  * is currently generally designed assuming the largest 16M size is used such
@@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
 	u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
 	u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
 	/* The MMIO offsets for Flex EU registers aren't contiguous */
-	u32 flex_mmio[] = {
-		i915_mmio_reg_offset(EU_PERF_CNTL0),
-		i915_mmio_reg_offset(EU_PERF_CNTL1),
-		i915_mmio_reg_offset(EU_PERF_CNTL2),
-		i915_mmio_reg_offset(EU_PERF_CNTL3),
-		i915_mmio_reg_offset(EU_PERF_CNTL4),
-		i915_mmio_reg_offset(EU_PERF_CNTL5),
-		i915_mmio_reg_offset(EU_PERF_CNTL6),
+	i915_reg_t flex_regs[] = {
+		EU_PERF_CNTL0,
+		EU_PERF_CNTL1,
+		EU_PERF_CNTL2,
+		EU_PERF_CNTL3,
+		EU_PERF_CNTL4,
+		EU_PERF_CNTL5,
+		EU_PERF_CNTL6,
 	};
 	int i;
 
-	reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
-	reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
-				      GEN8_OA_TIMER_PERIOD_SHIFT) |
-				     (dev_priv->perf.oa.periodic ?
-				      GEN8_OA_TIMER_ENABLE : 0) |
-				     GEN8_OA_COUNTER_RESUME;
+	CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+		(dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
+		(dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+		GEN8_OA_COUNTER_RESUME);
 
-	for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+	for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
 		u32 state_offset = ctx_flexeu0 + i * 2;
-		u32 mmio = flex_mmio[i];
+		u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
 
 		/*
 		 * This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1676,8 +1675,7 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
 			}
 		}
 
-		reg_state[state_offset] = mmio;
-		reg_state[state_offset+1] = value;
+		CTX_REG(reg_state, state_offset, flex_regs[i], value);
 	}
 }
 
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-13  8:02 ` [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro Tvrtko Ursulin
@ 2018-08-13  8:16   ` Chris Wilson
  2018-08-13  9:11     ` Tvrtko Ursulin
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2018-08-13  8:16 UTC (permalink / raw)
  To: Intel-gfx, Tvrtko Ursulin

Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> 
> Abstract the context image access a bit.
> 
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
>  1 file changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 49597cf31707..ccb20230df2c 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -210,6 +210,7 @@
>  #include "i915_oa_cflgt3.h"
>  #include "i915_oa_cnl.h"
>  #include "i915_oa_icl.h"
> +#include "intel_lrc_reg.h"
>  
>  /* HW requires this to be a power of two, between 128k and 16M, though driver
>   * is currently generally designed assuming the largest 16M size is used such
> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>         u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>         u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>         /* The MMIO offsets for Flex EU registers aren't contiguous */
> -       u32 flex_mmio[] = {
> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
> +       i915_reg_t flex_regs[] = {
> +               EU_PERF_CNTL0,
> +               EU_PERF_CNTL1,
> +               EU_PERF_CNTL2,
> +               EU_PERF_CNTL3,
> +               EU_PERF_CNTL4,
> +               EU_PERF_CNTL5,
> +               EU_PERF_CNTL6,
>         };
>         int i;
>  
> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
> -                                    (dev_priv->perf.oa.periodic ?
> -                                     GEN8_OA_TIMER_ENABLE : 0) |
> -                                    GEN8_OA_COUNTER_RESUME;
> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
> +               GEN8_OA_COUNTER_RESUME);

I'll be honest but, I don't think it's CTX_REG() that helps improve the
readability here. 

The really odd part is that this sticks itself into a bare part of the
register state not surrounded by any LRI and after a BB_END. This
routine can only work for established contexts, it should not work for
execlists_init_reg_state.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ✓ Fi.CI.BAT: success for Reviewed perf cleanups
  2018-08-13  8:02 [CI 0/2] Reviewed perf cleanups Tvrtko Ursulin
  2018-08-13  8:02 ` [CI 1/2] drm/i915/perf: simplify configure all context function Tvrtko Ursulin
  2018-08-13  8:02 ` [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro Tvrtko Ursulin
@ 2018-08-13  8:33 ` Patchwork
  2018-08-13 10:00 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 0 replies; 15+ messages in thread
From: Patchwork @ 2018-08-13  8:33 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Series Details ==

Series: Reviewed perf cleanups
URL   : https://patchwork.freedesktop.org/series/48100/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4660 -> Patchwork_9926 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/48100/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9926 that come from known issues:

  === IGT changes ===

    ==== Possible fixes ====

    igt@drv_selftest@live_hangcheck:
      fi-skl-guc:         DMESG-FAIL (fdo#107174) -> PASS

    igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
      {fi-byt-clapper}:   FAIL (fdo#107362) -> PASS

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-skl-guc:         FAIL (fdo#103191) -> PASS

    
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362


== Participating hosts (54 -> 49) ==

  Missing    (5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

    * Linux: CI_DRM_4660 -> Patchwork_9926

  CI_DRM_4660: 9cd882754c1017e68ed9d2c8d57dc326530522fe @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4592: fce9638b2e60afce872b3056c19a729b1b3708be @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9926: fbf730a0a4a717a5f3a151e398f50ca6b9de1757 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fbf730a0a4a7 drm/i915/perf: reuse intel_lrc ctx regs macro
fecf631c038e drm/i915/perf: simplify configure all context function

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9926/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-13  8:16   ` Chris Wilson
@ 2018-08-13  9:11     ` Tvrtko Ursulin
  2018-08-13  9:16       ` Chris Wilson
  0 siblings, 1 reply; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-13  9:11 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 13/08/2018 09:16, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>
>> Abstract the context image access a bit.
>>
>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
>>   1 file changed, 16 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
>> index 49597cf31707..ccb20230df2c 100644
>> --- a/drivers/gpu/drm/i915/i915_perf.c
>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>> @@ -210,6 +210,7 @@
>>   #include "i915_oa_cflgt3.h"
>>   #include "i915_oa_cnl.h"
>>   #include "i915_oa_icl.h"
>> +#include "intel_lrc_reg.h"
>>   
>>   /* HW requires this to be a power of two, between 128k and 16M, though driver
>>    * is currently generally designed assuming the largest 16M size is used such
>> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>>          u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>>          u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>>          /* The MMIO offsets for Flex EU registers aren't contiguous */
>> -       u32 flex_mmio[] = {
>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
>> +       i915_reg_t flex_regs[] = {
>> +               EU_PERF_CNTL0,
>> +               EU_PERF_CNTL1,
>> +               EU_PERF_CNTL2,
>> +               EU_PERF_CNTL3,
>> +               EU_PERF_CNTL4,
>> +               EU_PERF_CNTL5,
>> +               EU_PERF_CNTL6,
>>          };
>>          int i;
>>   
>> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
>> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
>> -                                    (dev_priv->perf.oa.periodic ?
>> -                                     GEN8_OA_TIMER_ENABLE : 0) |
>> -                                    GEN8_OA_COUNTER_RESUME;
>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
>> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
>> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
>> +               GEN8_OA_COUNTER_RESUME);
> 
> I'll be honest but, I don't think it's CTX_REG() that helps improve the
> readability here.
> 
> The really odd part is that this sticks itself into a bare part of the
> register state not surrounded by any LRI and after a BB_END. This
> routine can only work for established contexts, it should not work for
> execlists_init_reg_state.

Unless I am missing something change is completely mechanical, so any 
question marks you have are already there, right? What do you suggest is 
the action here?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-13  9:11     ` Tvrtko Ursulin
@ 2018-08-13  9:16       ` Chris Wilson
  2018-08-14 18:49         ` Tvrtko Ursulin
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2018-08-13  9:16 UTC (permalink / raw)
  To: Intel-gfx, Tvrtko Ursulin, Tvrtko Ursulin

Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
> 
> On 13/08/2018 09:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> >> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >>
> >> Abstract the context image access a bit.
> >>
> >> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >> ---
> >>   drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
> >>   1 file changed, 16 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> >> index 49597cf31707..ccb20230df2c 100644
> >> --- a/drivers/gpu/drm/i915/i915_perf.c
> >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >> @@ -210,6 +210,7 @@
> >>   #include "i915_oa_cflgt3.h"
> >>   #include "i915_oa_cnl.h"
> >>   #include "i915_oa_icl.h"
> >> +#include "intel_lrc_reg.h"
> >>   
> >>   /* HW requires this to be a power of two, between 128k and 16M, though driver
> >>    * is currently generally designed assuming the largest 16M size is used such
> >> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
> >>          u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> >>          u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> >>          /* The MMIO offsets for Flex EU registers aren't contiguous */
> >> -       u32 flex_mmio[] = {
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
> >> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
> >> +       i915_reg_t flex_regs[] = {
> >> +               EU_PERF_CNTL0,
> >> +               EU_PERF_CNTL1,
> >> +               EU_PERF_CNTL2,
> >> +               EU_PERF_CNTL3,
> >> +               EU_PERF_CNTL4,
> >> +               EU_PERF_CNTL5,
> >> +               EU_PERF_CNTL6,
> >>          };
> >>          int i;
> >>   
> >> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> >> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
> >> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
> >> -                                    (dev_priv->perf.oa.periodic ?
> >> -                                     GEN8_OA_TIMER_ENABLE : 0) |
> >> -                                    GEN8_OA_COUNTER_RESUME;
> >> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> >> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
> >> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
> >> +               GEN8_OA_COUNTER_RESUME);
> > 
> > I'll be honest but, I don't think it's CTX_REG() that helps improve the
> > readability here.
> > 
> > The really odd part is that this sticks itself into a bare part of the
> > register state not surrounded by any LRI and after a BB_END. This
> > routine can only work for established contexts, it should not work for
> > execlists_init_reg_state.
> 
> Unless I am missing something change is completely mechanical, so any 
> question marks you have are already there, right? What do you suggest is 
> the action here?

Sure, the only thing I question of this patch itself is whether
CTX_REG() is simply too much horrible obfuscating magic.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ✓ Fi.CI.IGT: success for Reviewed perf cleanups
  2018-08-13  8:02 [CI 0/2] Reviewed perf cleanups Tvrtko Ursulin
                   ` (2 preceding siblings ...)
  2018-08-13  8:33 ` ✓ Fi.CI.BAT: success for Reviewed perf cleanups Patchwork
@ 2018-08-13 10:00 ` Patchwork
  2018-08-31 15:27   ` Chris Wilson
  3 siblings, 1 reply; 15+ messages in thread
From: Patchwork @ 2018-08-13 10:00 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: intel-gfx

== Series Details ==

Series: Reviewed perf cleanups
URL   : https://patchwork.freedesktop.org/series/48100/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9926_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_9926_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_suspend@fence-restore-untiled:
      shard-glk:          PASS -> FAIL (fdo#103375)

    igt@drv_suspend@shrink:
      shard-apl:          PASS -> FAIL (fdo#106886)

    igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
      shard-snb:          PASS -> INCOMPLETE (fdo#105411)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    
    ==== Possible fixes ====

    igt@gem_eio@reset-stress:
      shard-apl:          FAIL -> PASS

    
  fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4660 -> Patchwork_9926

  CI_DRM_4660: 9cd882754c1017e68ed9d2c8d57dc326530522fe @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4592: fce9638b2e60afce872b3056c19a729b1b3708be @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9926: fbf730a0a4a717a5f3a151e398f50ca6b9de1757 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9926/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-13  9:16       ` Chris Wilson
@ 2018-08-14 18:49         ` Tvrtko Ursulin
  2018-08-14 18:57           ` Chris Wilson
  0 siblings, 1 reply; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-14 18:49 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 13/08/2018 10:16, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
>>
>> On 13/08/2018 09:16, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
>>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>
>>>> Abstract the context image access a bit.
>>>>
>>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
>>>>    1 file changed, 16 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
>>>> index 49597cf31707..ccb20230df2c 100644
>>>> --- a/drivers/gpu/drm/i915/i915_perf.c
>>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>>>> @@ -210,6 +210,7 @@
>>>>    #include "i915_oa_cflgt3.h"
>>>>    #include "i915_oa_cnl.h"
>>>>    #include "i915_oa_icl.h"
>>>> +#include "intel_lrc_reg.h"
>>>>    
>>>>    /* HW requires this to be a power of two, between 128k and 16M, though driver
>>>>     * is currently generally designed assuming the largest 16M size is used such
>>>> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>>>>           u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>>>>           u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>>>>           /* The MMIO offsets for Flex EU registers aren't contiguous */
>>>> -       u32 flex_mmio[] = {
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
>>>> +       i915_reg_t flex_regs[] = {
>>>> +               EU_PERF_CNTL0,
>>>> +               EU_PERF_CNTL1,
>>>> +               EU_PERF_CNTL2,
>>>> +               EU_PERF_CNTL3,
>>>> +               EU_PERF_CNTL4,
>>>> +               EU_PERF_CNTL5,
>>>> +               EU_PERF_CNTL6,
>>>>           };
>>>>           int i;
>>>>    
>>>> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>>>> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
>>>> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>> -                                    (dev_priv->perf.oa.periodic ?
>>>> -                                     GEN8_OA_TIMER_ENABLE : 0) |
>>>> -                                    GEN8_OA_COUNTER_RESUME;
>>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
>>>> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
>>>> +               GEN8_OA_COUNTER_RESUME);
>>>
>>> I'll be honest but, I don't think it's CTX_REG() that helps improve the
>>> readability here.
>>>
>>> The really odd part is that this sticks itself into a bare part of the
>>> register state not surrounded by any LRI and after a BB_END. This
>>> routine can only work for established contexts, it should not work for
>>> execlists_init_reg_state.
>>
>> Unless I am missing something change is completely mechanical, so any
>> question marks you have are already there, right? What do you suggest is
>> the action here?
> 
> Sure, the only thing I question of this patch itself is whether
> CTX_REG() is simply too much horrible obfuscating magic.

Turn a blind eye if the perceived badness factor is below some 
threshold? Following patch depends on this one, so if I have to drop 
this one, then I have to rework the next one etc.. well, it's not the 
worst problem, so yeah, whatever. Make a call and let me know.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-14 18:49         ` Tvrtko Ursulin
@ 2018-08-14 18:57           ` Chris Wilson
  2018-08-15  8:49             ` Tvrtko Ursulin
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2018-08-14 18:57 UTC (permalink / raw)
  To: Intel-gfx, Tvrtko Ursulin, Tvrtko Ursulin

Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
> 
> On 13/08/2018 10:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
> >>
> >> On 13/08/2018 09:16, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> >>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >>>>
> >>>> Abstract the context image access a bit.
> >>>>
> >>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>> ---
> >>>>    drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
> >>>>    1 file changed, 16 insertions(+), 18 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> >>>> index 49597cf31707..ccb20230df2c 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_perf.c
> >>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >>>> @@ -210,6 +210,7 @@
> >>>>    #include "i915_oa_cflgt3.h"
> >>>>    #include "i915_oa_cnl.h"
> >>>>    #include "i915_oa_icl.h"
> >>>> +#include "intel_lrc_reg.h"
> >>>>    
> >>>>    /* HW requires this to be a power of two, between 128k and 16M, though driver
> >>>>     * is currently generally designed assuming the largest 16M size is used such
> >>>> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
> >>>>           u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> >>>>           u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> >>>>           /* The MMIO offsets for Flex EU registers aren't contiguous */
> >>>> -       u32 flex_mmio[] = {
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
> >>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
> >>>> +       i915_reg_t flex_regs[] = {
> >>>> +               EU_PERF_CNTL0,
> >>>> +               EU_PERF_CNTL1,
> >>>> +               EU_PERF_CNTL2,
> >>>> +               EU_PERF_CNTL3,
> >>>> +               EU_PERF_CNTL4,
> >>>> +               EU_PERF_CNTL5,
> >>>> +               EU_PERF_CNTL6,
> >>>>           };
> >>>>           int i;
> >>>>    
> >>>> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> >>>> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
> >>>> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>>> -                                    (dev_priv->perf.oa.periodic ?
> >>>> -                                     GEN8_OA_TIMER_ENABLE : 0) |
> >>>> -                                    GEN8_OA_COUNTER_RESUME;
> >>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> >>>> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>>> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
> >>>> +               GEN8_OA_COUNTER_RESUME);
> >>>
> >>> I'll be honest but, I don't think it's CTX_REG() that helps improve the
> >>> readability here.
> >>>
> >>> The really odd part is that this sticks itself into a bare part of the
> >>> register state not surrounded by any LRI and after a BB_END. This
> >>> routine can only work for established contexts, it should not work for
> >>> execlists_init_reg_state.
> >>
> >> Unless I am missing something change is completely mechanical, so any
> >> question marks you have are already there, right? What do you suggest is
> >> the action here?
> > 
> > Sure, the only thing I question of this patch itself is whether
> > CTX_REG() is simply too much horrible obfuscating magic.
> 
> Turn a blind eye if the perceived badness factor is below some 
> threshold? Following patch depends on this one, so if I have to drop 
> this one, then I have to rework the next one etc.. well, it's not the 
> worst problem, so yeah, whatever. Make a call and let me know.

The patch was fine, just worrying about the surrounding code.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-14 18:57           ` Chris Wilson
@ 2018-08-15  8:49             ` Tvrtko Ursulin
  2018-08-15 10:50               ` Lionel Landwerlin
  0 siblings, 1 reply; 15+ messages in thread
From: Tvrtko Ursulin @ 2018-08-15  8:49 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin


On 14/08/2018 19:57, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
>>
>> On 13/08/2018 10:16, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
>>>>
>>>> On 13/08/2018 09:16, Chris Wilson wrote:
>>>>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
>>>>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>>
>>>>>> Abstract the context image access a bit.
>>>>>>
>>>>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/i915/i915_perf.c | 34 +++++++++++++++-----------------
>>>>>>     1 file changed, 16 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
>>>>>> index 49597cf31707..ccb20230df2c 100644
>>>>>> --- a/drivers/gpu/drm/i915/i915_perf.c
>>>>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>>>>>> @@ -210,6 +210,7 @@
>>>>>>     #include "i915_oa_cflgt3.h"
>>>>>>     #include "i915_oa_cnl.h"
>>>>>>     #include "i915_oa_icl.h"
>>>>>> +#include "intel_lrc_reg.h"
>>>>>>     
>>>>>>     /* HW requires this to be a power of two, between 128k and 16M, though driver
>>>>>>      * is currently generally designed assuming the largest 16M size is used such
>>>>>> @@ -1636,27 +1637,25 @@ static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>>>>>>            u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>>>>>>            u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>>>>>>            /* The MMIO offsets for Flex EU registers aren't contiguous */
>>>>>> -       u32 flex_mmio[] = {
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
>>>>>> +       i915_reg_t flex_regs[] = {
>>>>>> +               EU_PERF_CNTL0,
>>>>>> +               EU_PERF_CNTL1,
>>>>>> +               EU_PERF_CNTL2,
>>>>>> +               EU_PERF_CNTL3,
>>>>>> +               EU_PERF_CNTL4,
>>>>>> +               EU_PERF_CNTL5,
>>>>>> +               EU_PERF_CNTL6,
>>>>>>            };
>>>>>>            int i;
>>>>>>     
>>>>>> -       reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>>>>>> -       reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
>>>>>> -                                     GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>> -                                    (dev_priv->perf.oa.periodic ?
>>>>>> -                                     GEN8_OA_TIMER_ENABLE : 0) |
>>>>>> -                                    GEN8_OA_COUNTER_RESUME;
>>>>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
>>>>>> +               (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>> +               (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
>>>>>> +               GEN8_OA_COUNTER_RESUME);
>>>>>
>>>>> I'll be honest but, I don't think it's CTX_REG() that helps improve the
>>>>> readability here.
>>>>>
>>>>> The really odd part is that this sticks itself into a bare part of the
>>>>> register state not surrounded by any LRI and after a BB_END. This
>>>>> routine can only work for established contexts, it should not work for
>>>>> execlists_init_reg_state.
>>>>
>>>> Unless I am missing something change is completely mechanical, so any
>>>> question marks you have are already there, right? What do you suggest is
>>>> the action here?
>>>
>>> Sure, the only thing I question of this patch itself is whether
>>> CTX_REG() is simply too much horrible obfuscating magic.
>>
>> Turn a blind eye if the perceived badness factor is below some
>> threshold? Following patch depends on this one, so if I have to drop
>> this one, then I have to rework the next one etc.. well, it's not the
>> worst problem, so yeah, whatever. Make a call and let me know.
> 
> The patch was fine, just worrying about the surrounding code.

I misunderstood. So only about ctx_oactxctrl_offset and 
ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I have 
not idea. CC-ing Lionel in case he can shed some light on it.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-15  8:49             ` Tvrtko Ursulin
@ 2018-08-15 10:50               ` Lionel Landwerlin
  2018-08-15 10:56                 ` Chris Wilson
  0 siblings, 1 reply; 15+ messages in thread
From: Lionel Landwerlin @ 2018-08-15 10:50 UTC (permalink / raw)
  To: Tvrtko Ursulin, Chris Wilson, Intel-gfx, Tvrtko Ursulin

On 15/08/18 09:49, Tvrtko Ursulin wrote:
>
> On 14/08/2018 19:57, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
>>>
>>> On 13/08/2018 10:16, Chris Wilson wrote:
>>>> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
>>>>>
>>>>> On 13/08/2018 09:16, Chris Wilson wrote:
>>>>>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
>>>>>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>>>
>>>>>>> Abstract the context image access a bit.
>>>>>>>
>>>>>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>> ---
>>>>>>>     drivers/gpu/drm/i915/i915_perf.c | 34 
>>>>>>> +++++++++++++++-----------------
>>>>>>>     1 file changed, 16 insertions(+), 18 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
>>>>>>> b/drivers/gpu/drm/i915/i915_perf.c
>>>>>>> index 49597cf31707..ccb20230df2c 100644
>>>>>>> --- a/drivers/gpu/drm/i915/i915_perf.c
>>>>>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>>>>>>> @@ -210,6 +210,7 @@
>>>>>>>     #include "i915_oa_cflgt3.h"
>>>>>>>     #include "i915_oa_cnl.h"
>>>>>>>     #include "i915_oa_icl.h"
>>>>>>> +#include "intel_lrc_reg.h"
>>>>>>>         /* HW requires this to be a power of two, between 128k 
>>>>>>> and 16M, though driver
>>>>>>>      * is currently generally designed assuming the largest 16M 
>>>>>>> size is used such
>>>>>>> @@ -1636,27 +1637,25 @@ static void 
>>>>>>> gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>>>>>>>            u32 ctx_oactxctrl = 
>>>>>>> dev_priv->perf.oa.ctx_oactxctrl_offset;
>>>>>>>            u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>>>>>>>            /* The MMIO offsets for Flex EU registers aren't 
>>>>>>> contiguous */
>>>>>>> -       u32 flex_mmio[] = {
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
>>>>>>> +       i915_reg_t flex_regs[] = {
>>>>>>> +               EU_PERF_CNTL0,
>>>>>>> +               EU_PERF_CNTL1,
>>>>>>> +               EU_PERF_CNTL2,
>>>>>>> +               EU_PERF_CNTL3,
>>>>>>> +               EU_PERF_CNTL4,
>>>>>>> +               EU_PERF_CNTL5,
>>>>>>> +               EU_PERF_CNTL6,
>>>>>>>            };
>>>>>>>            int i;
>>>>>>>     -       reg_state[ctx_oactxctrl] = 
>>>>>>> i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>>>>>>> -       reg_state[ctx_oactxctrl+1] = 
>>>>>>> (dev_priv->perf.oa.period_exponent <<
>>>>>>> - GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>>> - (dev_priv->perf.oa.periodic ?
>>>>>>> - GEN8_OA_TIMER_ENABLE : 0) |
>>>>>>> - GEN8_OA_COUNTER_RESUME;
>>>>>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
>>>>>>> +               (dev_priv->perf.oa.period_exponent << 
>>>>>>> GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>>> +               (dev_priv->perf.oa.periodic ? 
>>>>>>> GEN8_OA_TIMER_ENABLE : 0) |
>>>>>>> +               GEN8_OA_COUNTER_RESUME);
>>>>>>
>>>>>> I'll be honest but, I don't think it's CTX_REG() that helps 
>>>>>> improve the
>>>>>> readability here.
>>>>>>
>>>>>> The really odd part is that this sticks itself into a bare part 
>>>>>> of the
>>>>>> register state not surrounded by any LRI and after a BB_END. This
>>>>>> routine can only work for established contexts, it should not 
>>>>>> work for
>>>>>> execlists_init_reg_state.
>>>>>
>>>>> Unless I am missing something change is completely mechanical, so any
>>>>> question marks you have are already there, right? What do you 
>>>>> suggest is
>>>>> the action here?
>>>>
>>>> Sure, the only thing I question of this patch itself is whether
>>>> CTX_REG() is simply too much horrible obfuscating magic.
>>>
>>> Turn a blind eye if the perceived badness factor is below some
>>> threshold? Following patch depends on this one, so if I have to drop
>>> this one, then I have to rework the next one etc.. well, it's not the
>>> worst problem, so yeah, whatever. Make a call and let me know.
>>
>> The patch was fine, just worrying about the surrounding code.
>
> I misunderstood. So only about ctx_oactxctrl_offset and 
> ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I 
> have not idea. CC-ing Lionel in case he can shed some light on it.

Those are the offsets at which the hardware will store the 
OA_CTXCTRL/FLEX_EU registers values as documented.
I can see that's it's a bit odd not to have the MI_LRI written before we 
do the first restore.

I'm 99% sure I've verified in practice that application started after 
i915/perf is opened have the right values programmed.
Not completely sure that the IGT tests cover that case though.
So maybe there is a problem with the first restore...

What's the value set into most register that aren't explicitly 
programmed in intel_lrc.c ?

-
Lionel

>
> Regards,
>
> Tvrtko
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-15 10:50               ` Lionel Landwerlin
@ 2018-08-15 10:56                 ` Chris Wilson
  2018-08-15 11:15                   ` Lionel Landwerlin
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2018-08-15 10:56 UTC (permalink / raw)
  To: Intel-gfx, Lionel Landwerlin, Tvrtko Ursulin, Tvrtko Ursulin

Quoting Lionel Landwerlin (2018-08-15 11:50:55)
> On 15/08/18 09:49, Tvrtko Ursulin wrote:
> >
> > On 14/08/2018 19:57, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
> >>>
> >>> On 13/08/2018 10:16, Chris Wilson wrote:
> >>>> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
> >>>>>
> >>>>> On 13/08/2018 09:16, Chris Wilson wrote:
> >>>>>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> >>>>>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >>>>>>>
> >>>>>>> Abstract the context image access a bit.
> >>>>>>>
> >>>>>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> >>>>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>>>>> ---
> >>>>>>>     drivers/gpu/drm/i915/i915_perf.c | 34 
> >>>>>>> +++++++++++++++-----------------
> >>>>>>>     1 file changed, 16 insertions(+), 18 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> >>>>>>> b/drivers/gpu/drm/i915/i915_perf.c
> >>>>>>> index 49597cf31707..ccb20230df2c 100644
> >>>>>>> --- a/drivers/gpu/drm/i915/i915_perf.c
> >>>>>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >>>>>>> @@ -210,6 +210,7 @@
> >>>>>>>     #include "i915_oa_cflgt3.h"
> >>>>>>>     #include "i915_oa_cnl.h"
> >>>>>>>     #include "i915_oa_icl.h"
> >>>>>>> +#include "intel_lrc_reg.h"
> >>>>>>>         /* HW requires this to be a power of two, between 128k 
> >>>>>>> and 16M, though driver
> >>>>>>>      * is currently generally designed assuming the largest 16M 
> >>>>>>> size is used such
> >>>>>>> @@ -1636,27 +1637,25 @@ static void 
> >>>>>>> gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
> >>>>>>>            u32 ctx_oactxctrl = 
> >>>>>>> dev_priv->perf.oa.ctx_oactxctrl_offset;
> >>>>>>>            u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> >>>>>>>            /* The MMIO offsets for Flex EU registers aren't 
> >>>>>>> contiguous */
> >>>>>>> -       u32 flex_mmio[] = {
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
> >>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
> >>>>>>> +       i915_reg_t flex_regs[] = {
> >>>>>>> +               EU_PERF_CNTL0,
> >>>>>>> +               EU_PERF_CNTL1,
> >>>>>>> +               EU_PERF_CNTL2,
> >>>>>>> +               EU_PERF_CNTL3,
> >>>>>>> +               EU_PERF_CNTL4,
> >>>>>>> +               EU_PERF_CNTL5,
> >>>>>>> +               EU_PERF_CNTL6,
> >>>>>>>            };
> >>>>>>>            int i;
> >>>>>>>     -       reg_state[ctx_oactxctrl] = 
> >>>>>>> i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> >>>>>>> -       reg_state[ctx_oactxctrl+1] = 
> >>>>>>> (dev_priv->perf.oa.period_exponent <<
> >>>>>>> - GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>>>>>> - (dev_priv->perf.oa.periodic ?
> >>>>>>> - GEN8_OA_TIMER_ENABLE : 0) |
> >>>>>>> - GEN8_OA_COUNTER_RESUME;
> >>>>>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
> >>>>>>> +               (dev_priv->perf.oa.period_exponent << 
> >>>>>>> GEN8_OA_TIMER_PERIOD_SHIFT) |
> >>>>>>> +               (dev_priv->perf.oa.periodic ? 
> >>>>>>> GEN8_OA_TIMER_ENABLE : 0) |
> >>>>>>> +               GEN8_OA_COUNTER_RESUME);
> >>>>>>
> >>>>>> I'll be honest but, I don't think it's CTX_REG() that helps 
> >>>>>> improve the
> >>>>>> readability here.
> >>>>>>
> >>>>>> The really odd part is that this sticks itself into a bare part 
> >>>>>> of the
> >>>>>> register state not surrounded by any LRI and after a BB_END. This
> >>>>>> routine can only work for established contexts, it should not 
> >>>>>> work for
> >>>>>> execlists_init_reg_state.
> >>>>>
> >>>>> Unless I am missing something change is completely mechanical, so any
> >>>>> question marks you have are already there, right? What do you 
> >>>>> suggest is
> >>>>> the action here?
> >>>>
> >>>> Sure, the only thing I question of this patch itself is whether
> >>>> CTX_REG() is simply too much horrible obfuscating magic.
> >>>
> >>> Turn a blind eye if the perceived badness factor is below some
> >>> threshold? Following patch depends on this one, so if I have to drop
> >>> this one, then I have to rework the next one etc.. well, it's not the
> >>> worst problem, so yeah, whatever. Make a call and let me know.
> >>
> >> The patch was fine, just worrying about the surrounding code.
> >
> > I misunderstood. So only about ctx_oactxctrl_offset and 
> > ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I 
> > have not idea. CC-ing Lionel in case he can shed some light on it.
> 
> Those are the offsets at which the hardware will store the 
> OA_CTXCTRL/FLEX_EU registers values as documented.
> I can see that's it's a bit odd not to have the MI_LRI written before we 
> do the first restore.
> 
> I'm 99% sure I've verified in practice that application started after 
> i915/perf is opened have the right values programmed.
> Not completely sure that the IGT tests cover that case though.
> So maybe there is a problem with the first restore...
> 
> What's the value set into most register that aren't explicitly 
> programmed in intel_lrc.c ?

That would be whatever was previously there

In practice, since we now initialise all real contexts from the default
state, the LRI will be there. execlists_init_reg_state() is wonderfully,
perhaps dangerously, misleading atm.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro
  2018-08-15 10:56                 ` Chris Wilson
@ 2018-08-15 11:15                   ` Lionel Landwerlin
  0 siblings, 0 replies; 15+ messages in thread
From: Lionel Landwerlin @ 2018-08-15 11:15 UTC (permalink / raw)
  To: Chris Wilson, Intel-gfx, Tvrtko Ursulin, Tvrtko Ursulin

On 15/08/18 11:56, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2018-08-15 11:50:55)
>> On 15/08/18 09:49, Tvrtko Ursulin wrote:
>>> On 14/08/2018 19:57, Chris Wilson wrote:
>>>> Quoting Tvrtko Ursulin (2018-08-14 19:49:46)
>>>>> On 13/08/2018 10:16, Chris Wilson wrote:
>>>>>> Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
>>>>>>> On 13/08/2018 09:16, Chris Wilson wrote:
>>>>>>>> Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
>>>>>>>>> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>>>>>
>>>>>>>>> Abstract the context image access a bit.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>>>>>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>>>> ---
>>>>>>>>>      drivers/gpu/drm/i915/i915_perf.c | 34
>>>>>>>>> +++++++++++++++-----------------
>>>>>>>>>      1 file changed, 16 insertions(+), 18 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/i915/i915_perf.c
>>>>>>>>> b/drivers/gpu/drm/i915/i915_perf.c
>>>>>>>>> index 49597cf31707..ccb20230df2c 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/i915_perf.c
>>>>>>>>> +++ b/drivers/gpu/drm/i915/i915_perf.c
>>>>>>>>> @@ -210,6 +210,7 @@
>>>>>>>>>      #include "i915_oa_cflgt3.h"
>>>>>>>>>      #include "i915_oa_cnl.h"
>>>>>>>>>      #include "i915_oa_icl.h"
>>>>>>>>> +#include "intel_lrc_reg.h"
>>>>>>>>>          /* HW requires this to be a power of two, between 128k
>>>>>>>>> and 16M, though driver
>>>>>>>>>       * is currently generally designed assuming the largest 16M
>>>>>>>>> size is used such
>>>>>>>>> @@ -1636,27 +1637,25 @@ static void
>>>>>>>>> gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
>>>>>>>>>             u32 ctx_oactxctrl =
>>>>>>>>> dev_priv->perf.oa.ctx_oactxctrl_offset;
>>>>>>>>>             u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>>>>>>>>>             /* The MMIO offsets for Flex EU registers aren't
>>>>>>>>> contiguous */
>>>>>>>>> -       u32 flex_mmio[] = {
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL0),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL1),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL2),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL3),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL4),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL5),
>>>>>>>>> -               i915_mmio_reg_offset(EU_PERF_CNTL6),
>>>>>>>>> +       i915_reg_t flex_regs[] = {
>>>>>>>>> +               EU_PERF_CNTL0,
>>>>>>>>> +               EU_PERF_CNTL1,
>>>>>>>>> +               EU_PERF_CNTL2,
>>>>>>>>> +               EU_PERF_CNTL3,
>>>>>>>>> +               EU_PERF_CNTL4,
>>>>>>>>> +               EU_PERF_CNTL5,
>>>>>>>>> +               EU_PERF_CNTL6,
>>>>>>>>>             };
>>>>>>>>>             int i;
>>>>>>>>>      -       reg_state[ctx_oactxctrl] =
>>>>>>>>> i915_mmio_reg_offset(GEN8_OACTXCONTROL);
>>>>>>>>> -       reg_state[ctx_oactxctrl+1] =
>>>>>>>>> (dev_priv->perf.oa.period_exponent <<
>>>>>>>>> - GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>>>>> - (dev_priv->perf.oa.periodic ?
>>>>>>>>> - GEN8_OA_TIMER_ENABLE : 0) |
>>>>>>>>> - GEN8_OA_COUNTER_RESUME;
>>>>>>>>> +       CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
>>>>>>>>> +               (dev_priv->perf.oa.period_exponent <<
>>>>>>>>> GEN8_OA_TIMER_PERIOD_SHIFT) |
>>>>>>>>> +               (dev_priv->perf.oa.periodic ?
>>>>>>>>> GEN8_OA_TIMER_ENABLE : 0) |
>>>>>>>>> +               GEN8_OA_COUNTER_RESUME);
>>>>>>>> I'll be honest but, I don't think it's CTX_REG() that helps
>>>>>>>> improve the
>>>>>>>> readability here.
>>>>>>>>
>>>>>>>> The really odd part is that this sticks itself into a bare part
>>>>>>>> of the
>>>>>>>> register state not surrounded by any LRI and after a BB_END. This
>>>>>>>> routine can only work for established contexts, it should not
>>>>>>>> work for
>>>>>>>> execlists_init_reg_state.
>>>>>>> Unless I am missing something change is completely mechanical, so any
>>>>>>> question marks you have are already there, right? What do you
>>>>>>> suggest is
>>>>>>> the action here?
>>>>>> Sure, the only thing I question of this patch itself is whether
>>>>>> CTX_REG() is simply too much horrible obfuscating magic.
>>>>> Turn a blind eye if the perceived badness factor is below some
>>>>> threshold? Following patch depends on this one, so if I have to drop
>>>>> this one, then I have to rework the next one etc.. well, it's not the
>>>>> worst problem, so yeah, whatever. Make a call and let me know.
>>>> The patch was fine, just worrying about the surrounding code.
>>> I misunderstood. So only about ctx_oactxctrl_offset and
>>> ctx_flexeu0_offset from i915_perf.c? Maybe that is some OA magic, I
>>> have not idea. CC-ing Lionel in case he can shed some light on it.
>> Those are the offsets at which the hardware will store the
>> OA_CTXCTRL/FLEX_EU registers values as documented.
>> I can see that's it's a bit odd not to have the MI_LRI written before we
>> do the first restore.
>>
>> I'm 99% sure I've verified in practice that application started after
>> i915/perf is opened have the right values programmed.
>> Not completely sure that the IGT tests cover that case though.
>> So maybe there is a problem with the first restore...
>>
>> What's the value set into most register that aren't explicitly
>> programmed in intel_lrc.c ?
> That would be whatever was previously there
>
> In practice, since we now initialise all real contexts from the default
> state, the LRI will be there. execlists_init_reg_state() is wonderfully,
> perhaps dangerously, misleading atm.
> -Chris
>
Then I guess it's all fine :)
Thanks,

-
Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: ✓ Fi.CI.IGT: success for Reviewed perf cleanups
  2018-08-13 10:00 ` ✓ Fi.CI.IGT: " Patchwork
@ 2018-08-31 15:27   ` Chris Wilson
  0 siblings, 0 replies; 15+ messages in thread
From: Chris Wilson @ 2018-08-31 15:27 UTC (permalink / raw)
  To: Patchwork, Tvrtko Ursulin; +Cc: intel-gfx

Quoting Patchwork (2018-08-13 11:00:57)
> == Series Details ==
> 
> Series: Reviewed perf cleanups
> URL   : https://patchwork.freedesktop.org/series/48100/
> State : success
> 
> == Summary ==
> 
> = CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9926_full =
> 
> == Summary - SUCCESS ==
> 
>   No regressions found.

And pushed. Ta,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2018-08-31 15:27 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-13  8:02 [CI 0/2] Reviewed perf cleanups Tvrtko Ursulin
2018-08-13  8:02 ` [CI 1/2] drm/i915/perf: simplify configure all context function Tvrtko Ursulin
2018-08-13  8:02 ` [CI 2/2] drm/i915/perf: reuse intel_lrc ctx regs macro Tvrtko Ursulin
2018-08-13  8:16   ` Chris Wilson
2018-08-13  9:11     ` Tvrtko Ursulin
2018-08-13  9:16       ` Chris Wilson
2018-08-14 18:49         ` Tvrtko Ursulin
2018-08-14 18:57           ` Chris Wilson
2018-08-15  8:49             ` Tvrtko Ursulin
2018-08-15 10:50               ` Lionel Landwerlin
2018-08-15 10:56                 ` Chris Wilson
2018-08-15 11:15                   ` Lionel Landwerlin
2018-08-13  8:33 ` ✓ Fi.CI.BAT: success for Reviewed perf cleanups Patchwork
2018-08-13 10:00 ` ✓ Fi.CI.IGT: " Patchwork
2018-08-31 15:27   ` Chris Wilson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.