Does anyone know the reason, why the clSetKernelArg uses only the argument index to specify the argument instead of the argument parameter name?
i think that the specification (maybe the OpenCL 1.1) should handle also the setting of the argument by it's name, not only by it's index number:
cl_int clSetKernelArg (cl_kernel kernel, const char *arg_name, size_t arg_size, const void *arg_value);
i'll appreciate any comments or ideas about this strange situation.
PS: is there a way (except parsing the opencl code file by the program itself) to get the number of kernel argument by it's parameter name? This would solve the issue mentioned above. I miss such a query using clGetKernelInfo.
Except for parsing the OpenCL code file itself there is currently in CL 1.0 no way to get the kernel argument info.
I'm not convinced about adding a variant of clSetKernelArg that takes an argument name. clSetKernelArg gets called quite a bit and we want to keep the # of cycles it takes to process clSetKernelArg to the minimum possible. Another way to solve what you are asking for would be to provide queries that return the number of kernel arguments, the kernel argument name given an argument index etc.
thx for your reply. you're right that setting the value of an kernel argument with a string would take more cycles but this makes to difference if the values are set while another kernel is still running on the gpu (i know that this does not count using OpenCL on CPUs/CELL). surely the 'setting by kernel parameter number' should not be removed for this reason, but can be an auxiliary feature.
the current clSetKernelArg still seems to be a subset of the way to set uniform variables in the GLSL language (GLSL is the reason why i miss such a feature). using GLSL, you queried the id for the variable (something similar than the kernel argument) and then you could set the value of the variable using this id. i'll really welcome a solution like this in the upcoming version.