In CUDA, launching a kernel means specifying its arguments, marshaled via an array of pointers:
CUresult cuLaunchKernel (
CUfunction f,
/* launch config stuff */,
void** kernelParams,
/* snip */ );
CUresult cuLaunchKernelEx (
const CUlaunchConfig* config,
CUfunction f,
void** kernelParams,
/* snip */ ) ;
and after the launch - you've still got that array of pointers to argument values, and you can do whatever you want with it: Launch again, alter and then launch etc.
In OpenCL, though, kernel arguments are set one-by-one, and opaquely:
cl_int clSetKernelArg(
cl_kernel kernel,
cl_uint arg_index,
size_t arg_size,
const void* arg_value);
So, you set, set, set a few times, then launch the kernel (using clEnqueueNDRangeKernel()
). The interesting aspect of this is that cl_kernel
does not represent just a piece of device-side-executable code, but rather additional state, including the arguments you've set.
My question is: What assumptions can I make about this state, and the arguments I've set, after a launch of a kernel? Can I assume everything is as it was just before the launch, and I can alter just some arguments, keeping the rest, for another launch of the same kernel? Or - are they invalidated/lost somehow, and have to be fully set again? ... and maybe this is implementation-dependent?
In CUDA, launching a kernel means specifying its arguments, marshaled via an array of pointers:
CUresult cuLaunchKernel (
CUfunction f,
/* launch config stuff */,
void** kernelParams,
/* snip */ );
CUresult cuLaunchKernelEx (
const CUlaunchConfig* config,
CUfunction f,
void** kernelParams,
/* snip */ ) ;
and after the launch - you've still got that array of pointers to argument values, and you can do whatever you want with it: Launch again, alter and then launch etc.
In OpenCL, though, kernel arguments are set one-by-one, and opaquely:
cl_int clSetKernelArg(
cl_kernel kernel,
cl_uint arg_index,
size_t arg_size,
const void* arg_value);
So, you set, set, set a few times, then launch the kernel (using clEnqueueNDRangeKernel()
). The interesting aspect of this is that cl_kernel
does not represent just a piece of device-side-executable code, but rather additional state, including the arguments you've set.
My question is: What assumptions can I make about this state, and the arguments I've set, after a launch of a kernel? Can I assume everything is as it was just before the launch, and I can alter just some arguments, keeping the rest, for another launch of the same kernel? Or - are they invalidated/lost somehow, and have to be fully set again? ... and maybe this is implementation-dependent?
Share Improve this question edited Jan 19 at 1:57 talonmies 72.4k35 gold badges202 silver badges289 bronze badges asked Jan 18 at 14:39 einpoklumeinpoklum 132k78 gold badges419 silver badges855 bronze badges1 Answer
Reset to default 1Kernel arguments are guaranteed to persist and do not change unless they overwritten.
After kernel launch, all kernel arguments remain the same.
After overwriting an individual kernel argument, only this overwritten argument will be changed and all the other kernel arguments remain unchanged.