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.
I'd like to call to_i64 on the type so i can use it as an array index
No need for a module.
Or if you want to abstract it futher:
type t
val index [n] 'a : [n]a -> t -> a
I'd like to not have to have that module at all, and just say "use this value as index"
For signed values, this is already possible, but i have some unsigned values as well
While thinking of an example i realized one needs to have a module anyway to restrict a type parameter
I was originally thinking of something like
let index [n] 't 'i (ts: [n]t) (index: i) = ts[i]but that won't compile regardless