Re: [Intel-gfx] [RFC 1/2] drm/i915: Engine discovery uAPI

[Gong, Zhipeng]

>-Original Message-
>From: Tvrtko Ursulin [mailto:tursu...@ursulin.net] 
>Sent: Wednesday, April 19, 2017 12:56 AM
>To: Intel-gfx@lists.freedesktop.org
>Cc: tursu...@ursulin.net; Ursulin, Tvrtko <tvrtko.ursu...@intel.com>; Ben 
>Widawsky <b...@bwidawsk.net>; Chris Wilson <ch...@chris-wilson.co.uk>; Vetter, 
>Daniel <daniel.vet...@intel.com>; Joonas Lahtinen 
><joonas.lahti...@linux.intel.com>; Bloomfield, Jon <jon.bloomfi...@intel.com>; 
>Charles, Daniel <daniel.char...@intel.com>; Rogozhkin, Dmitry V 
><dmitry.v.rogozh...@intel.com>; Mateo Lozano, Oscar <oscar.ma...@intel.com>; 
>Gong, Zhipeng <zhipeng.g...@intel.com>; intel-vaapi-me...@lists.01.org; 
>mesa-...@lists.freedesktop.org
Subject: [RFC 1/2] drm/i915: Engine discovery uAPI

>+u8 user_class_map[DRM_I915_ENGINE_CLASS_MAX] = {
>+  [DRM_I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
>+  [DRM_I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
>+  [DRM_I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
>+  [DRM_I915_ENGINE_CLASS_VIDEO_DECODE] = VIDEO_DECODE_CLASS,
>+  [DRM_I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS, };
>+

Not sure whether VIDEO_DECODE is a suitable name, since the same engine is also 
used in Media Encode. 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] SKL GT4e can not hit the max frequency

[Gong, Zhipeng]

We have two kinds of GT4e machines:
One has the maximum frequency of 800MHZ and the actual freq only hits 600MHZ.
The other has maximum frequency of 950MHZ and the actual freq only hits only 
hits 800MHZ.
Even if the gt_min_freq_mhz is set to the same value as gt_max_freq_mhz, the 
actual freq cannot hit the max.
Is there any special settings for SKL GT4e not in i915 module?

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Decouple execbuf uAPI from internal implementation

[Gong, Zhipeng]

> On Fri, Jan 15, 2016 at 03:12:50PM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > +   if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
> > +   unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
> > +
> > +   if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
> > +   bsd_idx = gen8_dispatch_bsd_ring(dev_priv, file);
> > +   } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
> > +  bsd_idx <= I915_EXEC_BSD_RING2) {
> > +   bsd_idx--;

There is one regression here, I915_EXEC_BSD_RING1/2 is left-shifted 13 bits, 
so we should add something like
bsd_idx >>= 13;
Otherwise the kernel panics. 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Question about LR context on VCS

[Gong, Zhipeng]

Hello

Intel MOCS/WA registers got initialized when LR context of RCS ring is created.
When one context uses only VCS ring and LR context of RCS ring is not created, 
what will the value of Intel MOCS/WA registers be? Undefined?

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Question about LR context on VCS

[Gong, Zhipeng]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, January 07, 2016 3:43 PM
> 
> On Thu, Jan 07, 2016 at 05:35:13AM +, Gong, Zhipeng wrote:
> > Hello
> >
> > Intel MOCS/WA registers got initialized when LR context of RCS ring is
> created.
> > When one context uses only VCS ring and LR context of RCS ring is not
> > created, what will the value of Intel MOCS/WA registers be? Undefined?
> 
> Even submitting a RCS batch first is no guarrantee that
> rcs_init_context() would be executed by the GPU before your VCS batch.
> 
> Yes, it is a known hole.
> -Chris

If call intel_lr_context_deferred_alloc(RCS) before 
intel_lr_context_deferred_alloc(VCS) by default, 
and wait for the init context request to be completed, can it work?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Gong, Zhipeng]

> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> 
> Do you also have a relative perf statistics like op/s we can compare to make
> sure we aren't just stalling the whole system?
> 
Could you please provide the commands about how to check it?
> 
> How much cpu time is left in the i915_wait_request branch? i.e. how close to
> the limit are we with chasing this path?
Could you please provide the commands here either? :)

-Zhipeng

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Gong, Zhipeng]

> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> On Tue, Nov 03, 2015 at 01:31:22PM +, Gong, Zhipeng wrote:
> >
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > >
> > > Do you also have a relative perf statistics like op/s we can compare
> > > to make sure we aren't just stalling the whole system?
> > >
> > Could you please provide the commands about how to check it?
> 
> I was presuming your workload has some measure of efficiency/throughput?
> It is one thing to say we are using 10% less CPU (per second), but the task is
> running 2x as long!
We use execute time as a measurement, the patch affects the execution time 
for our cases slightly.

Exec time(s)|   w/o patch   |   w/patch
---
BDW async 1 |65.00  |65.25
BDW async 5 |68.50  |66.42

> 
> > > How much cpu time is left in the i915_wait_request branch? i.e. how
> > > close to the limit are we with chasing this path?
> > Could you please provide the commands here either? :)
> 
> Check the perf callgraph.

Now the most of time is in io_schedule_timeout
__i915_wait_request  
|--64.04%-- io_schedule_timeout
|--22.04%-- intel_engine_add_wakeup
|--3.13%-- prepare_to_wait
|--2.99%-- gen6_rps_boost
|-...

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Gong, Zhipeng]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, November 02, 2015 5:59 PM
> To: Gong, Zhipeng
> Cc: intel-gfx@lists.freedesktop.org; Rogozhkin, Dmitry V
> Subject: Re: [PATCH] RFC drm/i915: Slaughter the thundering
> i915_wait_request herd
> 
> On Mon, Nov 02, 2015 at 05:39:54AM +, Gong, Zhipeng wrote:
> > Chris-
> >
> > The patch cannot be applied on the latest drm-intel-nightly directly.
> > I modified it a little bit to make it applied.
> > The patch can help much in HSW, but a little bit in BDW.
> > The test is to transcode 26 streams, which creates 244 threads.
> >
> > CPU util  | w/o patch  |   w/ patch
> > --
> > HSW async 1   |   102% | 61%
> > HSW async 5   |   114% | 46%
> > BDW async 1   |   116% | 116%
> > BDW async 5   |   111% | 107%
> 
> Could I get the perf report for the kernel time? One aspect that I find hard 
> to
> believe is that it is not the execbuf/mutex-contention that is the 
> ratelimiting
> step.

Sure, what command would you like to run with "perf"?

-Zhipeng
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Gong, Zhipeng]

It seems that there are some gaps in the patch and first patch. 
Like there is no this line in the first patch. 
  if (req->ring->seqno_barrier)

I have tried to apply this patch. And here is the cpu utilization and perf data 
on BDW

CPU util  | w/o patch  |   w/ patch
--
BDW async 1   |   116% | 95%
BDW async 5   |   111% | 91%

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, November 03, 2015 4:59 AM
> To: Gong, Zhipeng; intel-gfx@lists.freedesktop.org; Rogozhkin, Dmitry V
> Subject: Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering
> i915_wait_request herd
> 
> On Mon, Nov 02, 2015 at 03:28:22PM +, Chris Wilson wrote:
> > That should keep the worker alive for a further 10 jiffies, hopefully
> > long enough for the next wait to occur. The cost is that it keeps the
> > interrupt asserted (and to avoid that requires a little rearrangment
> > and probably a dedicated kthread for each ring).
> 
> Slightly better version that avoids keeping the interrupt active when not
> required:
> 


perf.data.tar.gz
Description: perf.data.tar.gz
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request herd

[Gong, Zhipeng]

Chris-

The patch cannot be applied on the latest drm-intel-nightly directly. 
I modified it a little bit to make it applied.
The patch can help much in HSW, but a little bit in BDW.
The test is to transcode 26 streams, which creates 244 threads.

CPU util  | w/o patch  |   w/ patch
--
HSW async 1   |   102% | 61%
HSW async 5   |   114% | 46%
BDW async 1   |   116% | 116%
BDW async 5   |   111% | 107%

-Zhipeng
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Saturday, October 31, 2015 6:35 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson; Rogozhkin, Dmitry V; Gong, Zhipeng
> Subject: [PATCH] RFC drm/i915: Slaughter the thundering i915_wait_request
> herd
> 
> One particularly stressful scenario consists of many independent tasks all
> competing for GPU time and waiting upon the results (e.g. realtime
> transcoding of many, many streams). One bottleneck in particular is that each
> client waits on its own results, but every client is woken up after every
> batchbuffer - hence the thunder of hooves as then every client must do its
> heavyweight dance to read a coherent seqno to see if it is the lucky one.
> Alternatively, we can have one worker responsible for wakeing after an
> interrupt, checking the seqno and only wakeing up the clients who are
> complete. The disadvantage is that in the uncontended scenario (i.e. only one
> waiter) we incur an extra context switch in the wakeup path - though that
> should be mitigated somewhat by the busywait we do first before sleeping.
> 
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozh...@intel.com>
> Cc: "Gong, Zhipeng" <zhipeng.g...@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h |   2 +-
>  drivers/gpu/drm/i915/i915_gem.c |  92 --
>  drivers/gpu/drm/i915/i915_gem_request.h |   6 ++
>  drivers/gpu/drm/i915/intel_lrc.c|   3 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 159
> +++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |   9 ++
>  6 files changed, 196 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3d4c422b3587..fe0d5ddad49d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1442,7 +1442,7 @@ struct i915_gpu_error {
>  #define I915_STOP_RING_ALLOW_WARN  (1 << 30)
> 
>   /* For missed irq/seqno simulation. */
> - unsigned int test_irq_rings;
> + unsigned long test_irq_rings;
>  };
> 
>  enum modeset_restore {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 29bd5238b824..1a89e7cc76d1
> 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1144,17 +1144,6 @@ i915_gem_check_wedge(unsigned reset_counter,
>   return 0;
>  }
> 
> -static void fake_irq(unsigned long data) -{
> - wake_up_process((struct task_struct *)data);
> -}
> -
> -static bool missed_irq(struct drm_i915_private *dev_priv,
> -struct intel_engine_cs *ring)
> -{
> - return test_bit(ring->id, _priv->gpu_error.missed_irq_rings);
> -}
> -
>  static int __i915_spin_request(struct drm_i915_gem_request *req)  {
>   unsigned long timeout;
> @@ -1199,27 +1188,17 @@ int __i915_wait_request(struct
> drm_i915_gem_request *req,
>   s64 *timeout,
>   struct intel_rps_client *rps)
>  {
> - struct intel_engine_cs *ring = i915_gem_request_get_ring(req);
> - struct drm_i915_private *dev_priv = req->i915;
> - const bool irq_test_in_progress =
> - ACCESS_ONCE(dev_priv->gpu_error.test_irq_rings) &
> intel_ring_flag(ring);
>   DEFINE_WAIT(wait);
> - unsigned long timeout_expire;
> + unsigned long timeout_remain;
>   s64 before, now;
>   int ret;
> 
> - WARN(!intel_irqs_enabled(dev_priv), "IRQs disabled");
> -
> - if (list_empty(>list))
> - return 0;
> -
>   if (i915_gem_request_completed(req, true))
>   return 0;
> 
> - timeout_expire = timeout ?
> - jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
> + timeout_remain = timeout ? nsecs_to_jiffies_timeout((u64)*timeout) :
> +0;
> 
> - intel_rps_boost(dev_priv, rps, req->emitted_jiffies);
> + intel_rps_boost(req->i915, rps, req->emitted_jiffies);
> 
>   /* Record current time in case interrupted by 

Re: [Intel-gfx] [PATCH 2/3] tests/gem_exec_params: check the invalid flags for dual bsd ring

[Gong, Zhipeng]

 -Original Message-
 From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
 Sent: Wednesday, January 21, 2015 5:44 AM
 To: Gong, Zhipeng
 Cc: intel-gfx; Vivi, Rodrigo
 Subject: Re: [Intel-gfx] [PATCH 2/3] tests/gem_exec_params: check the invalid
 flags for dual bsd ring
 
 I couldn't save my GT3 here for new tests, but on GT2 it fails:
 
 $ sudo ./gem_exec_params
 IGT-Version: 1.9-g85bc151 (x86_64) (Linux: 3.19.0-rc4+ x86_64) Subtest 
 control:
 SUCCESS (0.000s) Test requirement not met in function __real_main58, file
 gem_exec_params.c:108:
 Test requirement: !gem_has_bsd(fd)
 Subtest no-bsd: SKIP (0.000s)
 
 GT2 has BSD so it shouldn't skip here
no-bsd test requires that platform has no bsd ring, so it should be skipped for 
GT2. I don't change this test.
 
 Test requirement not met in function __real_main58, file
 gem_exec_params.c:113:
 Test requirement: !gem_has_blt(fd)
 Subtest no-blt: SKIP (0.000s)
 
 Same issue here!
no-blt test requires that platform has no bsd ring, so it should be skipped for 
GT2. I don't change this test.
 
 Test requirement not met in function __real_main58, file
 gem_exec_params.c:118:
 Test requirement: !gem_has_vebox(fd)
 Subtest no-vebox: SKIP (0.000s)
 
 Same issue here!
no-vebox test requires that platform has no bsd ring, so it should be skipped 
for GT2. I don't change this test.
 
 Subtest invalid-ring: SUCCESS (0.000s)
 Subtest invalid-ring2: SUCCESS (0.000s)
 Test requirement not met in function __real_main58, file
 gem_exec_params.c:133:
 Test requirement: gem_has_bsd2(fd)
 Subtest invalid-bsd-ring: SKIP (0.000s)
 
 This one should be the only SKIP in my BDW GT2.
Yes, it is skipped on GT2
 
 Thanks,
 Rodrigo.
 
 On Mon, Jan 12, 2015 at 4:50 PM, Zhipeng Gong zhipeng.g...@intel.com
 wrote:
  v2: add more tests to address Daniel's comments(Zhipeng)
 
  Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
  ---
   tests/gem_exec_params.c | 41
  +
   1 file changed, 41 insertions(+)
 
  diff --git a/tests/gem_exec_params.c b/tests/gem_exec_params.c index
  f63eda9..54f0dc3 100644
  --- a/tests/gem_exec_params.c
  +++ b/tests/gem_exec_params.c
  @@ -45,6 +45,9 @@
   #include igt_aux.h
 
   #define LOCAL_I915_EXEC_VEBOX (40)
  +#define LOCAL_I915_EXEC_BSD_MASK (313) #define
  +LOCAL_I915_EXEC_BSD_RING1 (113) #define
 LOCAL_I915_EXEC_BSD_RING2
  +(213)
 
   struct drm_i915_gem_execbuffer2 execbuf;  struct
  drm_i915_gem_exec_object2 gem_exec[1]; @@ -126,6 +129,44 @@
 igt_main
  RUN_FAIL(EINVAL);
  }
 
  +   igt_subtest(invalid-bsd-ring) {
  +   igt_require(gem_has_bsd2(fd));
  +   execbuf.flags = I915_EXEC_BSD |
 LOCAL_I915_EXEC_BSD_MASK;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd1-flag-on-render) {
  +   execbuf.flags = I915_EXEC_RENDER |
 LOCAL_I915_EXEC_BSD_RING1;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd2-flag-on-render) {
  +   execbuf.flags = I915_EXEC_RENDER |
 LOCAL_I915_EXEC_BSD_RING2;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd1-flag-on-blt) {
  +   execbuf.flags = I915_EXEC_BLT |
 LOCAL_I915_EXEC_BSD_RING1;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd2-flag-on-blt) {
  +   execbuf.flags = I915_EXEC_BLT |
 LOCAL_I915_EXEC_BSD_RING2;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd1-flag-on-vebox) {
  +   igt_require(gem_has_vebox(fd));
  +   execbuf.flags = LOCAL_I915_EXEC_VEBOX |
 LOCAL_I915_EXEC_BSD_RING1;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  +   igt_subtest(invalid-bsd2-flag-on-vebox) {
  +   igt_require(gem_has_vebox(fd));
  +   execbuf.flags = LOCAL_I915_EXEC_VEBOX |
 LOCAL_I915_EXEC_BSD_RING2;
  +   RUN_FAIL(EINVAL);
  +   }
  +
  igt_subtest(rel-constants-invalid-ring) {
  igt_require(gem_has_bsd(fd));
  execbuf.flags = I915_EXEC_BSD |
  I915_EXEC_CONSTANTS_ABSOLUTE;
  --
  1.8.3.1
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 
 
 --
 Rodrigo Vivi
 Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] test/gem_dummy_reloc_loop: add tests for dual bsd ring

[Gong, Zhipeng]

 -Original Message-
 From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
 Sent: Wednesday, January 21, 2015 5:49 AM
 To: Gong, Zhipeng
 Cc: intel-gfx; Vivi, Rodrigo
 Subject: Re: [Intel-gfx] [PATCH 3/3] test/gem_dummy_reloc_loop: add tests for
 dual bsd ring
 
 On Mon, Jan 12, 2015 at 4:50 PM, Zhipeng Gong zhipeng.g...@intel.com
 wrote:
  Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
  ---
   tests/gem_dummy_reloc_loop.c | 18 ++
   1 file changed, 18 insertions(+)
 
  diff --git a/tests/gem_dummy_reloc_loop.c
  b/tests/gem_dummy_reloc_loop.c index 335700d..5e0a10a 100644
  --- a/tests/gem_dummy_reloc_loop.c
  +++ b/tests/gem_dummy_reloc_loop.c
  @@ -43,6 +43,8 @@
   #include intel_chipset.h
 
   #define LOCAL_I915_EXEC_VEBOX (40)
  +#define LOCAL_I915_EXEC_BSD_RING1 (113) #define
  +LOCAL_I915_EXEC_BSD_RING2 (213)
 
   static drm_intel_bufmgr *bufmgr;
   struct intel_batchbuffer *batch;
  @@ -260,6 +262,22 @@ igt_main
  }
   #endif
 
  +   igt_subtest(bsd-ring1) {
  +   igt_require(gem_has_bsd2(fd));
 Should we really skip this if bsd2 isn't present?
 On my GT2:
 Test requirement not met in function __real_main179, file
 gem_dummy_reloc_loop.c:266:
 Test requirement: gem_has_bsd2(fd)
 Subtest bsd-ring1: SKIP (0.000s)
 
Yes, I915_EXEC_BSD_RING1 only take effects on the platform with 2VDBOX.
In kernel, the code is like this, it has a precondition of HAS_BSD2(dev).
if (HAS_BSD2(dev)) {
int ring_id;
switch (args-flags  I915_EXEC_BSD_MASK) {
...
case I915_EXEC_BSD_RING1:
ring = dev_priv-ring[VCS];
break;
...


  +   sleep(2);
  +   igt_info(running dummy loop on bsd-ring1\n);
  +
 dummy_reloc_loop(I915_EXEC_BSD|LOCAL_I915_EXEC_BSD_RING1);
  +   igt_info(dummy loop run on bsd-ring1 completed\n);
  +   }
  +
  +   igt_subtest(bsd-ring2) {
  +   igt_require(gem_has_bsd2(fd));
  +   sleep(2);
  +   igt_info(running dummy loop on bsd-ring2\n);
  +
 dummy_reloc_loop(I915_EXEC_BSD|LOCAL_I915_EXEC_BSD_RING2);
  +   igt_info(dummy loop run on bsd-ring2 completed\n);
  +   }
  +
  igt_subtest(mixed) {
  if (num_rings  1) {
  sleep(2);
  --
  1.8.3.1
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 
 
 --
 Rodrigo Vivi
 Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

[Gong, Zhipeng]

On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
 On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
  On Tue, Nov 25, 2014 at 5:04 AM, Daniel Vetter dan...@ffwll.ch wrote:
   On Mon, Nov 24, 2014 at 08:29:40AM -0800, Rodrigo Vivi wrote:
   From: Zhipeng Gong zhipeng.g...@intel.com
  
   On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
   has no control when using VCS1 or VCS2. This patch introduces a mechanism
   to avoid the default ping-pong mode and use one specific ring through
   execution flag.
  
   v2: fix whitespace (Rodrigo)
   v3: remove incorrect chunk that came on -collector rebase. (Rodrigo)
  
   Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
   Reviewed-by-by: Rodrigo Vivi rodrigo.v...@intel.com
   Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
  
   There's review from me pending on testcases and stuff, but I get the
   impression that's lost now. Is it?
  
  tests are ready as well, I've tested and reviewed them.
  imho this is ready for merge. Anyway I'm going to submit again on next
  -collector round
 
 Last time I've looked it doesn't really address my review. Quoting
 relevant parts:
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
  b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  index e1ed85a..d9081ec 100644
  --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  @@ -1273,8 +1273,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
  *data,
else if ((args-flags  I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
if (HAS_BSD2(dev)) {
int ring_id;
  - ring_id = gen8_dispatch_bsd_ring(dev, file);
  - ring = dev_priv-ring[ring_id];
  +
  + switch (args-flags  I915_EXEC_BSD_MASK) {
  + case I915_EXEC_BSD_DEFAULT:
  + ring_id = gen8_dispatch_bsd_ring(dev, file);
  + ring = dev_priv-ring[ring_id];
  + break;
  + case I915_EXEC_BSD_RING1:
  + ring = dev_priv-ring[VCS];
 
 Do we have any use-case for selecting ring1 specifically? I've thought
 it's only ring2 that is special?
The HEVC GPU commands should be dispatched to BSD RING 1 instead of BSD
RING2 as the two rings are asymmetrical. 
For the H264 decoding/encoding either ring is OK.
 
  + break;
  + case I915_EXEC_BSD_RING2:
 
 This needs a if (!IS_SKL(dev) return -EINVAL; check since the flag isnt
 valid anywhere else. 
The override flag is required for the asymmetrical BSD rings in SKL. But
it will be reasonable that user-space driver should have an opportunity
to determine which ring is to dispatch the BSD GPU command even though
the two rings are symmetrical, like BDW.
I will send out a new version of the patch to add more comments.
 Also you must add code to reject these flags if
 userspace selects a ring other than bsd.
if ((args-flags  I915_EXEC_RING_MASK) == I915_EXEC_BSD)  condition
checks already make sure that userspace would not select a ring other
than bsd.
 
 And all these new -EINVAL cases need new subtests to validate them in
 gem_exec_params.c.
 
 And I might have missed some case, ioctl validation is hard ;-) So please
 double-check that really no insane combination that userspace might try to
 abuse is caught and has a testcase in gem_exec_params.
 
 /endquote
 
 The testcase also doesn't check for these nasty condiditions (it would
 fail with the current patch).
Could you please give examples for nasty conditions, I will add them.
 -Daniel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Specify bsd rings through exec flag

[Gong, Zhipeng]

 
 On Tue, Aug 05, 2014 at 03:54:04PM +0800, Zhipeng Gong wrote:
  On Broadwell GT3 we have 2 Video Command Streamers (VCS), but 
  userspace has no control when using VCS1 or VCS2. This patch 
  introduces a mechanism to avoid the default ping-pong mode and use one 
  specific ring through execution flag.
  
  Signed-off-by: Zhipeng Gong zhipeng.g...@intel.com
  ---
   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 19 +--
   include/uapi/drm/i915_drm.h|  8 +++-
   2 files changed, 24 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
  b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  index 60998fc..f9ed8e0 100644
  --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
  @@ -1279,8 +1279,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
  *data,
  else if ((args-flags  I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
  if (HAS_BSD2(dev)) {
  int ring_id;
  -   ring_id = gen8_dispatch_bsd_ring(dev, file);
  -   ring = dev_priv-ring[ring_id];
  +
  +   switch (args-flags  I915_EXEC_BSD_MASK) {
  +   case I915_EXEC_BSD_DEFAULT:
  +   ring_id = gen8_dispatch_bsd_ring(dev, file);
  +   ring = dev_priv-ring[ring_id];
  +   break;
  +   case I915_EXEC_BSD_RING1:
  +   ring = dev_priv-ring[VCS];
  +   break;
  +   case I915_EXEC_BSD_RING2:
  +   ring = dev_priv-ring[VCS2];
  +   break;
  +   default:
  +   DRM_DEBUG(execbuf with unknown bsd ring: %d\n,
  + (int)(args-flags  
  I915_EXEC_BSD_MASK));
  +   return -EINVAL;
  +   }
  } else
  ring = dev_priv-ring[VCS];
  } else
  diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h 
  index ff57f07..421420a 100644
  --- a/include/uapi/drm/i915_drm.h
  +++ b/include/uapi/drm/i915_drm.h
  @@ -736,7 +736,13 @@ struct drm_i915_gem_execbuffer2 {
*/
   #define I915_EXEC_HANDLE_LUT   (112)
   
  -#define __I915_EXEC_UNKNOWN_FLAGS -(I915_EXEC_HANDLE_LUT1)
  +/** Used for switching BSD rings on the platforms with two BSD rings */
  +#define I915_EXEC_BSD_MASK (313)
  +#define I915_EXEC_BSD_DEFAULT  (013) /* default ping-pong 
  mode */
  +#define I915_EXEC_BSD_RING1(113)
  +#define I915_EXEC_BSD_RING2(213)
 
 There is room in the ring selection flags for expansion.
 -Chris

Hi Chris

There is only three rooms in the I915_EXEC_RING_MASK, this feature will
occupy two rooms. If use these rooms, it will left few rooms for more
possible rings in the future and it also introduces a little bit
complexity to get the ring in the i915_do_gem_execbuffer.

-Zhipeng

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx