Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Francois Dugast <francois.dugast@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t 3/5] lib/intel_compute: Allow the user to provide a custom compute kernel
Date: Fri, 21 Feb 2025 14:37:42 +0100	[thread overview]
Message-ID: <Z7iBpt1D-bEZUBJN@fdugast-desk> (raw)
In-Reply-To: <20250213070006.szwhib7r3bompjfz@zkempczy-mobl2>

Hi Zbigniew,

On Thu, Feb 13, 2025 at 08:00:06AM +0100, Zbigniew Kempczyński wrote:
> On Wed, Feb 05, 2025 at 11:17:04AM +0100, Francois Dugast wrote:
> > Allow the user to provide a custom compute kernel which will be used
> > instead of the default compute square one. This will be helpful to
> > try out corner cases which require a specific compute kernel.
> > 
> > Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> > ---
> >  lib/intel_compute.c | 26 ++++++++++++++++++--------
> >  lib/intel_compute.h |  2 ++
> >  2 files changed, 20 insertions(+), 8 deletions(-)
> > 
> > diff --git a/lib/intel_compute.c b/lib/intel_compute.c
> > index e0776fb6d..a826d58c0 100644
> > --- a/lib/intel_compute.c
> > +++ b/lib/intel_compute.c
> > @@ -1770,6 +1770,8 @@ static bool __run_intel_compute_kernel(int fd,
> >  	unsigned int batch;
> >  	const struct intel_compute_kernels *kernels = intel_compute_square_kernels;
> >  	enum intel_driver driver = get_intel_driver(fd);
> > +	const unsigned char *kernel;
> > +	unsigned int kernel_size;
> >  
> >  	for (batch = 0; batch < ARRAY_SIZE(intel_compute_batches); batch++) {
> >  		if (ip_ver == intel_compute_batches[batch].ip_ver)
> > @@ -1787,16 +1789,24 @@ static bool __run_intel_compute_kernel(int fd,
> >  		return false;
> >  	}
> >  
> > -	while (kernels->kernel) {
> > -		if (ip_ver == kernels->ip_ver)
> > -			break;
> > -		kernels++;
> > +	/* If the user provides a kernel, use it */
> > +	if (user && user->kernel) {
> > +		kernel = user->kernel;
> > +		kernel_size = user->kernel_size;
> > +	} else {
> > +		while (kernels->kernel) {
> > +			if (ip_ver == kernels->ip_ver)
> > +				break;
> > +			kernels++;
> > +		}
> > +		if (!kernels->kernel)
> > +			return false;
> > +		kernel = kernels->kernel;
> > +		kernel_size = kernels->size;
> 
> According to how we build pipeline indirect data we're limited to
> three arguments - *input, *output, count. Allowing the user to provide
> a custom kernel won't work unless type constraint will be met.
> I don't like this change, because someone who doesn't know how
> this work will start providing its own kernels will be surprised
> it doesn't work.

The way we statically build the pipeline indirect data is a good
balance of simplicity and flexibility, as we can test a lot even
with the constraint *input, *output, count.

More complex KMD tests will require simple specific kernels which
still comply with this constraint. For example the one below can
trigger a page fault at 0x10000 from the compute kernel context
so that we run other checks in KMD, all from IGT:

    __kernel void square(__global float* input,
                         __global float* output,
                         const unsigned int count) {
        int i = get_global_id(0);
        const __global uint* addr = 0x10000;
        output[i] = *addr;
    }

This is the reason for allowing custom compute kernels. This way
we can leverage the existing lib/intel_compute infrastructure to
test corner cases. I believe having this possibility is far more
important than the risk of a user incorrectly expecting IGT to
provide a full "compute runtime" able to run any kernel.

Would you be fine if the doc of struct user_execenv::kernel would
make the constraint of *input, *output, count explicit?

If not, what about replacing "const unsigned char *kernel" with
an enum which would be used to obtain the right kernel from a
library of "approved" kernels in intel_compute_kernels.c?

Francois

> 
> --
> Zbigniew
> 
> >  	}
> > -	if (!kernels->kernel)
> > -		return false;
> >  
> > -	intel_compute_batches[batch].compute_exec(fd, kernels->kernel,
> > -						  kernels->size, eci, user);
> > +	intel_compute_batches[batch].compute_exec(fd, kernel,
> > +						  kernel_size, eci, user);
> >  
> >  	return true;
> >  }
> > diff --git a/lib/intel_compute.h b/lib/intel_compute.h
> > index c4b4ee5e1..6096bb83a 100644
> > --- a/lib/intel_compute.h
> > +++ b/lib/intel_compute.h
> > @@ -35,6 +35,8 @@ struct intel_compute_kernels {
> >  
> >  struct user_execenv {
> >  	uint32_t vm;
> > +	const unsigned char *kernel;
> > +	unsigned int kernel_size;
> >  };
> >  
> >  extern const struct intel_compute_kernels intel_compute_square_kernels[];
> > -- 
> > 2.43.0
> > 

  reply	other threads:[~2025-02-21 13:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 10:17 [PATCH i-g-t 0/5] Prepare lib/intel_compute for SVM/system allocator Francois Dugast
2025-02-05 10:17 ` [PATCH i-g-t 1/5] lib/intel_compute: Rename variables for input and output data Francois Dugast
2025-02-05 10:17 ` [PATCH i-g-t 2/5] lib/intel_compute: Allow the user to provide a vm Francois Dugast
2025-02-05 10:17 ` [PATCH i-g-t 3/5] lib/intel_compute: Allow the user to provide a custom compute kernel Francois Dugast
2025-02-13  7:00   ` Zbigniew Kempczyński
2025-02-21 13:37     ` Francois Dugast [this message]
2025-02-24  7:17       ` Zbigniew Kempczyński
2025-02-05 10:17 ` [PATCH i-g-t 4/5] lib/intel_compute: Give option to skip results check Francois Dugast
2025-02-05 10:17 ` [PATCH i-g-t 5/5] lib/intel_compute: Allow the user to provide input and output buffers Francois Dugast
2025-02-05 13:04 ` ✗ GitLab.Pipeline: warning for Prepare lib/intel_compute for SVM/system allocator Patchwork
2025-02-05 13:31 ` ✓ i915.CI.BAT: success " Patchwork
2025-02-05 13:32 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-05 16:34 ` ✗ Xe.CI.Full: failure " Patchwork
2025-02-05 17:29 ` ✓ i915.CI.Full: success " 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=Z7iBpt1D-bEZUBJN@fdugast-desk \
    --to=francois.dugast@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox