PDA

View Full Version : Robustness



Spulenpfeifen
09-25-2011, 12:35 AM
Let me first say that I do appreciate the efforts made and I generally enjoy using OpenCL. Though, some issues arise when used outside of simple demos.

Correct me if I'm wrong but there seems to be no way for a OpenCL driver to tell whether a kernel argument is given correctly apart from it's size. So there is no way to tell apart a cl_mem object (_cl_mem pointer, 8 bytes on 64-bit) argument from an accidentally given float2 or similar sized argument resulting in a crash. As there is no easy way for a user to get kernel argument type information besides parsing the kernel himself using an implementation that quite possibly differs from the driver's implementation it leaves him with significant stability issues. An issue that could easily be avoided at the API design level in my opinion. So, please, either consider designing a more robust interface or give the user some good ways to verify sanity himself.

Thanks!

david.garcia
09-25-2011, 05:30 AM
Spulenpfeifen,


Correct me if I'm wrong but there seems to be no way for a OpenCL driver to tell whether a kernel argument is given correctly apart from it's size. So there is no way to tell apart a cl_mem object (_cl_mem pointer, 8 bytes on 64-bit) argument from an accidentally given float2 or similar sized argument resulting in a crash.

[...]

An issue that could easily be avoided at the API design level in my opinion.


Do you have any specific proposal? The working group did not want to add a different flavor of clSetKernelArg() for each of the possible types of kernel arguments. It would have required different functions for memory objects, samplers, structs, plus the cartesian product of {char, uchar, short, ushort, int, uint, long, ulong, half, float, double} builtin types and {1,2,3,4,8,16} vector lengths. That would amount to around 70 functions.

Spulenpfeifen
09-25-2011, 06:01 AM
Kernel argument type information would be very helpful in checking it myself. Shouldn't be too hard as this information is likely already availiable anyway.

Separate flavors for non-POD types would prevent the worst and shouldn't be too messy otherwise.

If both wouldn't work for you one function per type with a size argument (not 70) would be better than a crash, no?