Robust compatibility check? [closed] - c++

Question

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I'm building an application that uses OpenCL GPU acceleration on windows, including OpenCL 2.0+ features.
On my own machine, that has compatible HW and up-to-date drivers, I get no problems running the builds.
However, I've been deploying it to other machines and have been encountering freezes/crashing for various reasons during initialization of my OpenCL kernels/programs/etc.
The other machines have either incompatible HW (no gfx card or gfx card not compatible with OCL2.0+), out-of-date GFX drivers, out-of-date OpenCL drivers, etc. Simply updating them isn't a solution since they're meant to simulate real-world user environments (ie, the users I eventually deploy my software to are not guaranteed to have compatible systems).
I already track OpenCL-returned error codes (and stop further initialization once one is returned), but I'm still getting segmentation faults on these machines during initialization of the various OpenCL functions, or they will simply hang during OCL program initialization (in some circumstances, even when no OpenCL error codes are returned prior to running the problem functions).
How can I do a robust compatibility check on a particular machine, prior to running any OpenCL initialization functions?
I know I can query device/driver OpenCL info, but the return values are just vendor-specific strings and it seems like a fool's errand to try anticipating/parsing all possible combinations thereof (and further, it seems there's no guarantee they will even return helpful info at all). Is there a more robust way to query whether OpenCL (and specifically OpenCL 2.0 GPU-device code) can be executed on a particular machine?

Answer 1

There are 2 problems when people try to distribute OpenCL apps.
You want to check whether the client even has OpenCL.
You want to check whether the client has the correct version.
Solving 1 is a little pain in the ass since OpenCL apps would usually crash if there is no OpenCL. You can use CLEW which is basically glew for opencl. This will allow you to check if client has opencl or not.
After that all you have left is OpenCL device/driver querying functions to check if client has the correct version installed.

Answer 2

There are several possible incompatibility issues that you may encounter:
Extensions or Optional Core Features
Core language features are described in the OpenCL Specification, and
all features from core are supposed to work on any system and with any
compiler (provided that it supports particular version of OpenCL).
There is also a set of extensions, which are optional and you need to
check that they are supported on a system.
For example, if you use double type, you have to check that
cl_khr_fp64 extension is supported. You can get a list of supported
extensions by caling clGetDeviceInfo(CL_DEVICE_EXTENSIONS)
Undefined behavior or any other bug
When a program runs well on your local machine, and crashes/freezes
when you deploy it, this is often an indication of a bug in the
program itself.
This could happen if you (unintentionally) relied on an OpenCL driver
implementation details (e.g. how workgroups are ordered, how
work-items are executed). To avoid this, you should strictly follow
the rules of the OpenCL specification, although the specification is
not always perfect.
As an example, if you have the following code:
for (int i = 0; i < N; ++i) {
if (get_global_id() < M) {
barrier();
}
}
This code may happily run and give you correct results on your local
machine, but it is incorrect according to the OpenCL specification (you cannot
have a barrier() call in a divergent block), and it will
crash/hang/mismatch on other machine.
Compiler (or driver) bugs
Compilers try hard to optimize your program, but they sometimes fail
to do this correctly, especially in some edge cases. Probably the best
way to detect these kinds of bugs is to write a self-check tool, that
runs a unit test for the key parts of your program and checks the
result aginst a reference.
For example, if you have an algorithm, say Histogram computation, you
can isolate it from the rest of the program, and make sure you get the
expected results.
If this self-check tool fails, it can give you a clue on what is going
on, and you'll have a good reproducer that you can share with OpenCL
driver developers, so they can fix the problem.
Aside from that, you can apply a workaround based on a vendor id,
device type, driver version, etc. All this information can be queried
from clGetDeviceInfo, but you should not treat it as a stable
interface: names and versions can potentially change for future
releases, so it is hard to follow these changes.