All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: igt-dev@lists.freedesktop.org,
	Kamil Konieczny <kamil.konieczny@linux.intel.com>
Cc: "Kamil Konieczny" <kamil.konieczny@linux.intel.com>,
	"Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>,
	"Dominik Karol Piątkowski" <dominik.karol.piatkowski@intel.com>
Subject: Re: [PATCH i-g-t v13 5/5] tests/intel/gem_exec_gttfill: simplify multiGPU subtest
Date: Tue, 19 Mar 2024 10:36:49 +0100	[thread overview]
Message-ID: <2212029.vXnMlVU4IS@jkrzyszt-mobl2.ger.corp.intel.com> (raw)
In-Reply-To: <20240318132624.110746-6-kamil.konieczny@linux.intel.com>

Hi Kamil,

The series now looks good to me, however, I still have one doubt.

On Monday, 18 March 2024 14:26:23 CET Kamil Konieczny wrote:
> Simplify multi-GPU subtest with the help of new multigpu library.
> 
> v10: remove igt_require_multigpu() as it checks filters but we
>   want to use legacy opens (Kamil), correct Cc name (Zbigniew)
> 
> Cc: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
> Cc: "Dominik Karol Piątkowski" <dominik.karol.piatkowski@intel.com>
> Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> ---
>  tests/intel/gem_exec_gttfill.c | 13 +++----------
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/tests/intel/gem_exec_gttfill.c b/tests/intel/gem_exec_gttfill.c
> index b1063437b..1eb7325bb 100644
> --- a/tests/intel/gem_exec_gttfill.c
> +++ b/tests/intel/gem_exec_gttfill.c
> @@ -24,8 +24,8 @@
>  #include "i915/gem.h"
>  #include "i915/gem_create.h"
>  #include "igt.h"
> -#include "igt_device_scan.h"
>  #include "igt_rand.h"
> +#include "igt_multigpu.h"
>  /**
>   * TEST: gem exec gttfill
>   * Description: Fill the GTT with batches.
> @@ -251,7 +251,7 @@ igt_main
>  {
>  	const struct intel_execution_engine2 *e;
>  	const intel_ctx_t *ctx;
> -	int i915 = -1, gpu_count;
> +	int i915 = -1;
>  
>  	igt_fixture {
>  		i915 = drm_open_driver(DRIVER_INTEL);
> @@ -285,17 +285,11 @@ igt_main
>  	igt_fixture {
>  		igt_stop_hang_detector();
>  		intel_ctx_destroy(i915, ctx);
> -		// prepare multigpu tests
> -		gpu_count = igt_device_filter_count();
>  	}
>  
>  	igt_subtest("multigpu-basic") { /* run on two or more discrete cards */
> -		igt_require(gpu_count > 1);
> -		igt_multi_fork(child, gpu_count) {
> -			int g_fd;
> +		igt_multi_fork_foreach_gpu(g_fd, gpu_idx, DRIVER_INTEL) {
>  			// prepare
> -			g_fd = __drm_open_driver_another(child, DRIVER_INTEL);
> -			igt_assert(g_fd >= 0);

Since igt_multi_fork_foreach_gpu() now calls multigpu_open_another() which 
introduces igt_require_gem() into the processing path, you are effectively 
changing prerequisites before calling intel_ctx_create_all_physical().  Two 
questions arise:
1) Was that missing requirement for GEM on Intel intentional here, or was that 
   a bug which you are now fixing while being at it?
2) Do we expect all future users of igt_multi_fork_foreach_gpu() to always 
   require GEM on Intel?  If you think so then can you please explain why?

Wouldn't igt_multi_fork_foreach_gpu() be more versatile if it called 
drm_open_driver_another() instead, without that skip on no GEM?  Wouldn't it 
be more clear if tests were explicitly taking care as needed of such scenario 
specific prerequisites?

If you still see benefits from using multigpu_open_another() here then could 
we please plan for introducing two variants of igt_multi_fork_foreach_gpu(), 
one that doesn't skip and the other that skips on no GEM, unless you are sure 
we don't need the former?  Maybe the latter could be implemented as a wrapper 
around the former, while the opposite seems not doable.

Thanks,
Janusz

>  			ctx = intel_ctx_create_all_physical(g_fd);
>  			igt_fork_hang_detector(g_fd);
>  			// subtest
> @@ -303,7 +297,6 @@ igt_main
>  			// release resources
>  			igt_stop_hang_detector();
>  			intel_ctx_destroy(g_fd, ctx);
> -			drm_close_driver(g_fd);
>  		}
>  
>  		igt_waitchildren();
> 





  reply	other threads:[~2024-03-19  9:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 13:26 [PATCH i-g-t v13 0/5] introduce Xe multigpu and other multi-GPU helpers Kamil Konieczny
2024-03-18 13:26 ` [PATCH i-g-t v13 1/5] lib/igt_device_scan: Introduce filtering out non-PCI devices Kamil Konieczny
2024-03-18 13:26 ` [PATCH i-g-t v13 2/5] lib/drmtest: Introduced drm_open_driver_another Kamil Konieczny
2024-03-18 13:26 ` [PATCH i-g-t v13 3/5] lib/igt_multigpu: Introduce library for multi-GPU scenarios Kamil Konieczny
2024-03-18 13:26 ` [PATCH i-g-t v13 4/5] tests/intel/xe_exec_basic: add multigpu subtests Kamil Konieczny
2024-03-18 13:26 ` [PATCH i-g-t v13 5/5] tests/intel/gem_exec_gttfill: simplify multiGPU subtest Kamil Konieczny
2024-03-19  9:36   ` Janusz Krzysztofik [this message]
2024-03-20 14:55     ` Kamil Konieczny
2024-03-18 19:17 ` ✓ CI.xeBAT: success for introduce Xe multigpu and other multi-GPU helpers (rev13) Patchwork
2024-03-18 19:24 ` ✓ Fi.CI.BAT: " Patchwork
2024-03-19  2:23 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2212029.vXnMlVU4IS@jkrzyszt-mobl2.ger.corp.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=dominik.karol.piatkowski@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=zbigniew.kempczynski@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.