I’ve been testing OpenCL v1.2 on an Apple MacBook Pro and have encountered 2 (so far) issues where the Iris Pro behavior seems to be incorrect.
(1) When sampling an image, the Iris Pro yields a different interpolation to the clamped values. (Clamping specification: CLK_NORMALIZED_COORDS_FALSE | CLK_ADDRESS_CLAMP | CLK_FILTER_LINEAR)
(2) When using atomic_inc in a kernel the Iris Pro triggers a call to __pthread_kill from clWaitForEvents
The first issue was awkward (it causes unit tests to fail). The second issue is untenable (it causes unit testing to crash).
Is there a way to work around this issue other than excluding the Iris Pro?
P.S. Hardware specifics:
MacBook Pro (Retina, 15-inch, Mid 2014)
2.8 GHz Intel Core i7
NVIDIA GeForce GT 750M 2048 MB
Intel Iris Pro 1536 MB
Framework is what Apple provides:
Update: Additionally, a declaration of a local variable within kernel code results in a compile failure. (Works as it should for Core i7 and GT 750M.)
Hello AngelGabriel, would it be possible to provide more detail about these issues? If you can provide a simple reproducer that would be ideal, otherwise I’ll take as much information as you can provide.
- What built-in function are you using to sample the image? Are you using integer or floating point coordinates? What image channel data type are you sampling?
- Do you see this behavior with all kernels using atomic_inc or a specific kernel? If it’s a specific kernel, what is it doing?
- I presume this is a variable in the __local address space and not any local variable? Are you declaring the __local variable at kernel function scope (see section 6.5.2 of the OpenCL 1.2 spec)?
You may find a faster response to Intel bug reports by posting to the Intel OpenCL forums, here: https://software.intel.com/en-us/forums/opencl
We try to monitor other OpenCL forums (like this one) as well, but sometimes things slip through the cracks.
@bashbaug thank you for the response… I will put together minimal examples, but it may take me a few days to find the time.