[Mesa-dev] OpenCL for radeon Hawaii?

[Aaron Watry]

It looks like CLBlast makes the same mistake that the CLU library did until
recently (fixed in 435957d667bc22cdb2f0bdc32).

It assumes that if your system has OpenCL 2.0 headers installed that the
OpenCL platforms present on the system also support CL 2.0.

In the case of Mesa, it doesn't support clCreateCommandQueueWithProperties
which was introduced in CL 2.0, and so CLBlast (or the ocl icd) segfaults
when it tries to call that function.

The relevant code CLBlast (CLBlast/src/clpp11.hpp around line 388) is:
#ifdef CL_VERSION_2_0
  cl_queue_properties properties[] = {CL_QUEUE_PROPERTIES,
CL_QUEUE_PROFILING_ENABLE, 0};
  *queue_ = clCreateCommandQueueWithProperties(context(), device(),
properties, &status);
#else
  *queue_ = clCreateCommandQueue(context(), device(),
CL_QUEUE_PROFILING_ENABLE, &status);
#endif


The fix that I sent to CLU changed its code to call clGetPlatformInfo to
fetch CL_PLATFORM_VERSION, and then checked the returned string for "OpenCL
1." in order to check if clCreateCommandQueueWithProperties was safe to
invoke.

You still need some if-deffery to get it to compile against CL 1.x headers,
but at least it doesn't crash then and remains compatible.

Given that CLBlast claims to support CL 1.x, this should probably get filed
as a bug with them. When I modified the code in CLBlast to call
clCreateCommandQueue(), it stopped crashing and the clblast_test_xdot test
started passing.

Note: I found this using valgrind, which is always a great tool for
diagnosing crashing crashing C/C++ programs that you have the source (or
debug symbols) for.

--Aaron



On Wed, Aug 3, 2016 at 2:45 PM, Sam Halliday <sam.halliday at gmail.com> wrote:

> Hello everybody,
>
> I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which has
> mesa 12.0.1.
>
> I am keen to try out mesa's partial OpenCL implementation. Ideally to
> use a BLAS implementation such as https://github.com/CNugteren/CLBlast
> but I'd also be happy to just write something basic like dense
> matrix/matrix multiplication in OpenCL.
>
>
> However, when I tried to run the "luxmark" OpenCL benchmark (the only
> way I could think to test if my card is supported), I got this error
>
> [PathOCLBaseRenderThread::0] Compiling kernels
> [PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR
> clBuildProgram[CL_INVALID_BUILD_OPTIONS]:
> RUNTIME ERROR: PathOCLBase kernel compilation error
>
> which, I'm guessing, means that my GPU isn't supported for OpenCL by
> mesa yet. Is that correct? (I don't know how to get any more output or
> logs than this).
>
>
> Could somebody please help by letting me know if there is a ticket I
> could subscribe to track progress of support for my card (a simple
> search of the bug database didn't bring up anything obvious). This
> message is to the -dev list, so I am suppose I am saying that I am
> prepared to get my hands dirty... but I am primarily a Scala developer
> and haven't done any C in years so the extent of my help is limited.
>
> If somebody who knows what they are doing would be willing to implement
> some of the functionality needed, I'd be prepared to buy this GPU for
> them to use for their hacking - it's the least I could do (but it is an
> absolute monster, I didn't even know GPUs could be this big! I needed to
> get a bigger case for it).
>
>
> Somewhat tangentially, if OpenCL support is really not a possibility
> anytime soon, could somebody please point me in the direction of a way
> to use this card programmatically for something like matrix/matrix
> multiplication? (I'm prepared to go really low level if there is
> sufficient documentation).
>
>
> I'm not at all interested in using proprietary drivers for OpenCL.
>
>
> --
> Best regards,
> Sam
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160803/e69c19b1/attachment.html>