[SOLVED] ***Runtime error: reached an uninitialized image function***

[gudmundsson__dan]

Installed intel_sdk_for_opencl_2017_7.0.0.2568_x64/ for testing my kernels with CPU (and 2.1) and I got the error in the topic.

I must be doing something wrong but I can't figure it out, before reaching the kernel in the backtrace I run other more complex kernels which uses read_imagef(...).

The code works fine with intel-gpu (1.2) driver and Nvidia-gpu (1.2?) drivers.

Any ideas?

Trying to make debug info (-g -s <SRC>) available, causes seq-faults in earlier kernels (probably me failing to use gdb in the correct way), I don't get any debug symbols in that crash either.

The complete file is here https://github.com/dgud/wings/blob/master/shaders/img_lib.cl

__kernel void rgba_to_normal(__read_only image2d_t inImg, const int w, const int h, __global float4 *outImg)
{
const sampler_t sampler=CLK_NORMALIZED_COORDS_FALSE|CLK_ADDRESS_REPEAT;
int x = (int) get_global_id(0);
int y = (int) get_global_id(1);
if(x < w && y < h) {
float4 cx0 = read_imagef(inImg, sampler, (float2)(x, y));
outImg[y*w+x] = cx0*2.0f-1.0f;
}
}

(gdb) bt
#0  0x00007f77761ba6e1 in trap_function ()
#1  0x00007f7824e5dff7 in rgba_to_normal ()
#2  0x00007f7756b35dd9 in ?? () from /opt/intel/opencl/exp-runtime-2.1/lib64/libOclCpuBackEnd.so
#3  0x00007f775f125559 in ?? () from /opt/intel/opencl/exp-runtime-2.1/lib64/libcpu_device_2_1.so
#4  0x00007f775fa60c8a in ?? () from /opt/intel/opencl/exp-runtime-2.1/lib64/libtask_executor_2_1.so
#5  0x00007f775fa62280 in ?? () from /opt/intel/opencl/exp-runtime-2.1/lib64/libtask_executor_2_1.so
#6  0x00007f775fa62589 in ?? () from /opt/intel/opencl/exp-runtime-2.1/lib64/libtask_executor_2_1.so
#7  0x00007f775f5eb0c5 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x7f775d3b3e80, parent=..., child=0x0) at ../../src/tbb/custom_scheduler.h:474
#8  0x00007f775f5e68f2 in tbb::internal::arena::process (this=0x7f7755577510, s=...) at ../../src/tbb/arena.cpp:96
#9  0x00007f775f5e4c48 in tbb::internal::market::process (this=0x7f7755577510, j=...) at ../../src/tbb/market.cpp:495
#10 0x00007f775f5e0949 in tbb::internal::rml::private_server::remove_server_ref (this=<optimized out>, $`6=<optimized out>) at ../../src/tbb/private_server.cpp:275
#11 tbb::internal::rml::private_server::request_close_connection (this=0x7f7755577510) at ../../src/tbb/private_server.cpp:192
#12 0x00007f775f5e08d6 in tbb::internal::rml::private_worker::thread_routine (arg=0x7f7755577510) at ../../src/tbb/private_server.cpp:228
#13 0x00007f7869fa66ba in start_thread (arg=0x7f7755578700) at pthread_create.c:333
#14 0x00007f7869ad441d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[Michael_C_Intel1]

Hi DanG,

Can you try the production CPU runtime 16.1.2 instead of the experimental runtime included with the SDK?

• https://software.intel.com/en-us/articles/opencl-drivers
• https://software.intel.com/en-us/articles/opencl-drivers#cpu-section

Also, please can you ensure there isn't any deprecated OpenCL API 1.2 calls in the host side source if the kernel and implementation is built for 2.0 or 2.1? Ensure build options match? ex: -cl-std https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clBuildProgram.html

I'm assuming intel-gpu is beignet... can you share the CPU SKU on which you're executing?

-MichaelC

[gudmundsson__dan]

Thanks for the feedback, your answer will require that I experiment a bit, so it might take a while to get back to you.

Since I use erlang as programming language I use an OpenCL wrapper that tries to hide the version differences, so mixing version api calls is definitely a possibility. And 2.0 and 2.1 is rather untested paths for me.. cough nvidia cough.

But if I disable the two trivial kernels that causes the crashes, the other more complex kernels work fine (also uses image functionality), and the others are needed and the two that crashed was just for optimizations, so I'm happy :-)

"I'm assuming intel-gpu is beignet..." ??  does not compute (English is not my 1st language and googling beignet links to fried pastry)

I have the Linux machine at work so can't check CPU SKU right now, best guess  ~2012 Xeon 4c with 4 HT.

[Michael_C_Intel1]

DanG,

• No worries. Please give the production CPU runtime a try. Would love to hear feedback about your success or even a stack trace if the issue still persists there. It could be a productive filing.
• If there is some sort of 1.2 issue that doesn't work because the implementation is 2.x that  could be a useful filing too.
• Hopefully, the production CPU runtime instead of the experimental is a satisfactory resolution.
• Sidebar: Sorry for the communication mixup... 'beignet' happens to also be the name of an opencl implementation distributed for Intel processors prior to 6th gen Intel Core processors. My assumption is that if you pulled a package from the system package manager called intel-gpu, it was beignet. Some of the context is that beignet contributions from Intel were stopped infavor of Intel Graphics Compute Runtime for OpenCL Applications a.k.a. 'neo'. Our primary support targets are thus associated with the newer implementation.
  • Yes, it is also a pastry.
• Worth mentioning... the CPU implementations are backed by TBB... and some users have seen odd issues when mixing their already TBB application with the CPU runtimes which use TBB... particularly when using TBB configuration or runtime control parameters.
  • ​If you are using TBB it could be useful to know how.
  • We have some TBB usage safety mitigations in the upcoming release of the production CPU runtime.

-MichaelC

[gudmundsson__dan]

SOLVED IT

CPU SKU: model name : Intel(R) Xeon(R) CPU E31270 @ 3.40GHz

Same problem:

Using OpenCL via cpu:Name Intel(R) OpenCL:VSN: OpenCL 1.2 LINUX
***Runtime error: reached an uninitialized image function***
***Runtime error: reached an uninitialized image function***
...Trace/breakpoint trap (core dumped)

(gdb) bt

#0  0x00007f68decf13c5 in trap_function ()
#1  0x00007f68decff18e in rgba_to_normal ()
#2  0x00007f6839b0085f in ?? () from /opt/intel/opencl-1.2-6.4.0.37/lib64/libOclCpuBackEnd.so
#3  0x00007f68416d8cd9 in ?? () from /opt/intel/opencl-1.2-6.4.0.37/lib64/libcpu_device.so
#4  0x00007f6841e0b6aa in ?? () from /opt/intel/opencl-1.2-6.4.0.37/lib64/libtask_executor.so
#5  0x00007f6841e0c439 in ?? () from /opt/intel/opencl-1.2-6.4.0.37/lib64/libtask_executor.so
#6  0x00007f6841e0c7d9 in ?? () from /opt/intel/opencl-1.2-6.4.0.37/lib64/libtask_executor.so
#7  0x00007f6841a97b40 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x7f683aef3e00, parent=..., child=0x0) at ../../src/tbb/custom_scheduler.h:447
#8  0x00007f6841a93f09 in tbb::internal::arena::process (this=0x7f682bbfd510, s=...) at ../../src/tbb/arena.cpp:98
#9  0x00007f6841a924c5 in tbb::internal::market::process (this=0x7f682bbfd510, j=...) at ../../src/tbb/market.cpp:471
#10 0x00007f6841a8e5d4 in tbb::internal::rml::private_worker::run (this=0x7f682bbfd510) at ../../src/tbb/private_server.cpp:275
#11 0x00007f6841a8e506 in tbb::internal::rml::private_worker::thread_routine (arg=0x7f682bbfd510) at ../../src/tbb/private_server.cpp:232
#12 0x00007f6947e8f6ba in start_thread (arg=0x7f682bbfe700) at pthread_create.c:333
#13 0x00007f69479bd41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Finding that it didn't work for 1.2 either caused me to do some rubber ducking with a friend and found that using:

const sampler_t sampler=CLK_NORMALIZED_COORDS_FALSE|CLK_ADDRESS_REPEAT;

is undefined behavior so fixed that to:

const sampler_t sampler=CLK_NORMALIZED_COORDS_FALSE|CLK_ADDRESS_CLAMP|CLK_FILTER_LINEAR;

And problem solved, so your CPU drivers are a bit picky, but my code was clearly breaking the spec.

Super thanks for the help!!