Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Troels Henriksen
    @athas
    Indeed. They do not know better. You must show them the right path. This is the way.
    1 reply
    Philip Lassen
    @philass
    In order to get the Javascript/WASM to run with the test suite, would I also need to implement a js equivalent of values.py?
    Troels Henriksen
    @athas
    I suppose so, but you only need the binary format, which is trivial.
    snektron
    @snektron:matrix.org
    [m]
    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)
    Troels Henriksen
    @athas
    Futhark doesn't require more than 1.1, I think. Mesa is probably defective for other reasons. I've certainly never managed to get it to work.
    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.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    I think I wrote that somewhere because we only test on 1.2 devices, but looking at the OpenCL spec, I don't think we actually use anything past 1.0 yet.
    Snektron
    @snektron:matrix.org
    [m]
    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.
    Troels Henriksen
    @athas
    Oh. Yes. Probably Mesa does not support double precision. Futhark does have code that tries to only include the double precision parts of the runtime system when the program needs it, but I'm not sure we test that code path anymore.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    That pragma should be inserted by the compiler.
    Snektron
    @snektron:matrix.org
    [m]
    hm, mesa does report the device supporting cl_khr_fp64
    Troels Henriksen
    @athas
    Mesa has lied to me before. For example, it claimed to support OpenCL, but whenever I tried to run a kernel, my system would reboot.
    Snektron
    @snektron:matrix.org
    [m]
    wow
    doing a quick search in the generated c code after compiling with futhark opencl does not yield any cl_khr_fp64
    Troels Henriksen
    @athas
    Interesting. That would imply that the compiler doesn't think your program uses f64, but still includes parts of the supporting code. That's a very likely bug to creep in.
    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.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    That's really odd.
    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.
    Snektron
    @snektron:matrix.org
    [m]
    Hm, its still complaining about double's. Was there a way to dump the opencl source code to a file?
    Troels Henriksen
    @athas
    --dump-opencl kernels.cl
    Snektron
    @snektron:matrix.org
    [m]
    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 :)
    Troels Henriksen
    @athas
    Those bounds issues are nasty, but it is likely to be a bug in the Mesa compiler. AMD also had a bug where they miscompiled my gotos by mistakenly thinking they were loops.
    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.
    Snektron
    @snektron:matrix.org
    [m]
    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.
    Troels Henriksen
    @athas
    If the Mesa compiler miscompiles the code, it'll probably jump past the code that computes the index.
    Snektron
    @snektron:matrix.org
    [m]
    I guess as long as the other platforms work its not a critical problem.
    Troels Henriksen
    @athas
    I think it's disappointing that AMDs code quality is so relatively poor. I have hope it will improve, for two reasons: 0) generally increased funding due to the massive success of Ryzen. 1) The large AMD-based supercomputers they are contracted to support.
    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
    Snektron
    @snektron:matrix.org
    [m]
    Note that Mesa is not by AMD so AMD isn't really to blame here i think
    Troels Henriksen
    @athas
    I can't really blame Mesa for their bugs. They are short-staffed and focused on graphics, and their graphics implementation is very good indeed.
    Snektron
    @snektron:matrix.org
    [m]
    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.
    Troels Henriksen
    @athas
    I think AMD has more or less ditched their own OpenGL/Vulkan stack and just use Mesa on Linux.
    Snektron
    @snektron:matrix.org
    [m]
    Anyway
    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)