I am new to oneAPI and I am learning things on the fly. I am working on a project which has a nice set of openCL kernels. We will need a mix of openCL code and level 0 calls. I was reading on this forum:
Another users' code was getting a similar error and the "fix" was to export SYCL_BE=PI_OPENCL
This may work for part of my project, but eventually I also need to call level 0 API. Will these work together? Also how can I find what operation was "Invalid"?
Thanks for reaching out to us.
If you have openCL kernels and want to execute it with the DPCPP compiler then you have to use the OpenCL backend by setting the environment variable SYCL_BE=PI_OPENCL, as the default backend is Level0. This environment variable doesn't allow us to use multiple backends. With the Intel oneAPI toolkit you can only choose from OpenCL and Level0.
If you have both OpenCL kernels and dpcpp kernels then you can switch to OpenCL backend because Level0 backend will give an error with OpenCL kernels whereas OpenCL backend will work both kernels.
But there is a hack through which we can run your OpenCL kernels by keeping the default backend (Level0). The idea of the hack is to manually select a device(GPU) from the OpenCL platform and execute it with the default backend(Level0) without exporting the OpenCL backend, which will give you a feeling of mixed OpenCL and Level0.
Please refer to the below attached files for the samples. Please note it's not a standard solution, but you can consider it as a workaround to solve your issue.
To get to know the origin of invalid operations you can try using stdout statements before every execution of the queues/kernels or can check the debug logs by exporting SYCL_PI_TRACE=<value> environment variable.
Hope the provided details will help you to resolve your issues related to your use-case. Check the attached files for the workaround.
Sorry I did not update that a problem with a reference to a pointer in CPU memory was causing the problem. It would appear that a better error message complaining about the EUs not being able to access main memory would be better than CL_INVALID_OPERATION or if the documentation in oneAPI could be updated to say that a source of CL_INVALID_OPERATION is when a memory reference is not available inside a kernel. Even better would be warnings when compiling the calling code, but I understand OneAPI compiles kernels on the fly, so at the initial c++ compile, it might not be known that there are refences to pointers - but it is obvious when looked at.
So my problem is resolved. If anyone in the future hits this, look for memory pointer references that your kernel cannot access.