Is it an idea to add a check to the generated opencl whether a device supports the minimum required opencl version?
I have two OpenCL versions installed on my system, one is provided by mesa and only supports up to OpenCL 1.1, while the other one, which i ripped from amdgpu-pro, does support 1.2
unfortunately the mesa one appears first and i sometimes forget to pass
-d. I know its not much to type that, but i think its appropriate if the generated code also checks for it and skips any incompatible devices.
(i set up a build environment for futhark the other day so i'm fine with contributing this myself, but i just want to know if this would be an appropriate thing to add)
Since Mesa might work for some people and in some future, I don't like the idea of blacklisting it. Presumably people who install the Mesa ICD also do it for a reason. The only thing we blacklist is Apple's CPU device, because it is completely dysfunctional, and users cannot get rid of it.
I wasn't suggesting blacklisting, but rather checking whether a target device supports opencl 1.2. I thought i read somewhere that futhark requires opencl 1.2
Ah. In that case it might be something else: when i run under mesa, it complains that cl_khr_fp64 is not enabled for the f64 intrinsic functions.
Apparently that extension was promoted to core-optional in OpenCL 1.2, so thats why mesa is giving me trouble. Apparently all that is needed is a pragma in the OpenCL code, which is still accepted for backwards compat: https://www.khronos.org/registry/OpenCL//sdk/2.2/docs/man/html/cl_khr_fp64.html
Let me check if my device supports it, need to turn on my pc one sec
doing a quick search in the generated c code after compiling with futhark opencl does not yield any cl_khr_fp64
So first, does your program use f64?
1 reply
Ah, I see something.
We mistakenly defined
f32.sgn with double precision. I'll fix it.
Interestingly, my program now crashes with out-of-bounds when running under mesa, but not when running under amdgpu-pro or any other backend
I suppose that might be attributed to mesa shenanigans
Okay, I made some fixes to the double precision stuff.
I can't explain what might be going wrong with the out-of-bounds accesses.
Hm, its still complaining about double's. Was there a way to dump the opencl source code to a file?
Ah, whoops, i hadn't compiled in the most recent commit, sorry about that. It seems to run now (with the same bounds problems, but i'll look into those later). Thanks :)
You can try putting
#[unsafe] in front and see if that makes it run properly.
OpenCL interestingly does not have any restrictions on
goto, which is probably a mistake. There's no way a GPU can handle non-reducible control flow. But the only use of goto in the generated code is to break out of nested loops, which is reducible, so it really ought to work.
Unsafe does seem to work. Strange, because it does print some wild index that isn't supposed to happen at all.
Its a shame opencl implementations are plagued by these kinds of bugs. Unfortunately i also encountered things like implementations not adhering to alignment rules of struct members and some other nasty bugs.
I guess as long as the other platforms work its not a critical problem.
ROCm is undergoing very active development these days to support these supercomputers. Of course, active development doesn't necessarily imply a reduction in bugs...
2 replies
Note that Mesa is not by AMD so AMD isn't really to blame here i think
in fact, the amdgpu-pro implementation doesn't have these problems. I just think its sad that AMD doesn't upstream their improvements, its the least they could do really.
For my current iteration of the parser generator stuff, i generate a module that a parser module accepts. That module defines some other modules in turn, like which type is used to represent productions, for example.
The thing is though, that i only use that module structure because i'd like to use those types to index some generated arrays, so i pretty much only use
to_i64
Do you think there's a way around that, or should i just take the L and keep the module structure?
(the types are unsigned, which is why i can't use them as indices already)
You don't need an module just to carry a single type.