kpet / clvk Goto Github PK

When running the Solus repository version of opencl it returns the following error:

clinfo: ./build/libOpenCL.so.1: no version information available (required by clinfo) clinfo: relocation error: clinfo: symbol clGetExtensionFunctionAddress version OPENCL_1.0 not defined in file libOpenCL.so.1 with link time reference

Also tried running the PlaidML library at git commit plaidml/plaidml@8696156 but was as expected informed that no OpenCL devices were found. Sadly I'm not terribly experienced with OpenCL in general so I don't have much other information. If there is anything else I can try I would like to help in any way I can!

Setup:
OS: Solus
Kernel: 4.18.9
Vulkan: 1.1.82.0
LLVM: 6.0.1
clinfo: 2.2.18.04.06

See #25

Support for CL_MEM_USE_HOST_PTR in buffer mapping/unmapping is broken. The conformance test is hiding some of the issues since it updates the memory passed as host_ptr instead of computing a reference result in a separate allocation.

• fix clvk to pass the conformance test as is
• create CTS issue (KhronosGroup/OpenCL-CTS#700)
• improve conformance test (KhronosGroup/OpenCL-CTS#730)
• pass improved conformance test

Support buffer_ubo argument kinds.

Currently VK_DEVICE_LOST with no obvious cause (passes the validation layers).

• single 5 all
• multiple 5 all

I'm trying to build the project on macOS.

After getting the source, I make a build subdirectory and run

 cmake -G Ninja -DCMAKE_BUILD_TYPE=Release ..

It fails to configure, with the following error:

-- Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
/Users/dneto/project/clvk/clvk/src/Vulkan_INCLUDE_DIR
   used as include directory in directory /Users/dneto/project/clvk/clvk/src
Vulkan_LIBRARY (ADVANCED)
    linked by target "OpenCL" in directory /Users/dneto/project/clvk/clvk/src

-- Configuring incomplete, errors occurred!

What is the dependence on Vulkan?
Is it for the headers? What's the normal way of getting them? Is the normal flow to set up a Vulkan environment so it can be executed?

The problem appears to be a bug in clvk.

SPIR-V via the SPIRV-LLVM translator.

• Support using offline tools
• Support in online compilation mode

clspv doesn't accept -Ipath without a space. Liaise with them to change this or deal with it in the runtime.

cl_khr_int64_base_atomics and cl_khr_int64_extended_atomics.

Currently the information is printed directly by clspv.

Needs at least google/clspv#341

8-element and 16-element vectors

• Basic support
• Conversions
• Maths built-in functions
• ... and more :)

Should make test_basic/bufferreadwriterect pass in the conformance tests.

So we don't spend time arguing about braces and spaces in code reviews.

• Document process
• Put a bot in place to check changes

Testing CL_KERNEL_WORK_GROUP_SIZE query.

Can be done in clvk by inspecting the SPIR-V module using SPIR-V tools (prototyped this) but probably better done in clspv with a suitable interface to clvk.

Not all entrypoints have got logging implemented. Needs a full review of all entrypoints in src/api.cpp.

I've got a local prototype with a few tests but I'll happily throw it away and port the tests I have if someone is willing to take that on.

clCreateImage2D and clCreateImage3D. Probably best done by extracting a common cvk_create_image with the semantics of the new-style clCreateImage and using it in all three entrypoints.

Requires pointer-to-integer casts in clspv.

So others can easily run conformance tests.

Need to enable the arg metadata feature in clang/clspv and figure out an interface with clvk.
This should work when creating programs from binaries as well.

Depends on google/clspv#321

• Basic type support, constants and operators
• Conversions
• Math built-ins
• Common built-ins
• Geometric built-ins
• Relational built-ins
• Vector load/stores
• Async copies and prefetch
• Image built-ins
• Device queries

Depends on google/clspv#276

• Basic type support, constants and operators
• Conversions
• Math built-ins
• Common built-ins
• Geometric built-ins
• Relational built-ins
• Vector load/stores
• Async copies and prefetch
• Image built-ins
• Device queries

clvk currently relies on the descriptor map obtained from clspv to ascertain the existence of a kernel in a given program. Kernels with no arguments aren't described at all in the descriptor map and thus can't be used (kernel creation will fail). Not the most pressing thing to fix though :).