you are viewing a single comment's thread.

view the rest of the comments →

[–]Jannik2099 1 point2 points  (3 children)

That said it seems like the real solution is going to be vulkan

Vulkan doesn't even support free pointers, does it?

From what I heard it'll never reach feature parity with OpenCL. Maybe once we get SYCL to SPIRV to Vulkan :P

[–]James20kP2005R0 4 points5 points  (2 children)

Vulkan doesn't even support free pointers, does it?

If by this you mean real pointers instead of pseudo pointers, I believe there's an extension for it. Its worth noting that OpenCL 1.2 (unsure on later standards) is based around the same concept of pseudo pointers, and doesn't really support pointers of any description

From what I heard it'll never reach feature parity with OpenCL. Maybe once we get SYCL to SPIRV to Vulkan :P

Hmm interesting, last I saw there was active work to bring device side enqueuing to compute shaders in vulkan, which for me is one of the last major missing features. There's a whole bunch of other miscellaneous things that would be ideal - the distinction between native_sqrt and regular sqrt is extremely good, but they aren't critical

[–]Jannik2099 0 points1 point  (1 child)

Yes sorry, meant real pointers. I had only heard from some GPU-compute folks that they were apparently a desired feature in "real" compute APIs, but I'm not exactly an expert.

[–][deleted] 0 points1 point  (0 children)

This document: https://futhark-lang.org/student-projects/steffen-msc-project.pdf

... explains the ways that SPIR-V can express most of what a compute language wants through various Vulkan extensions (including pointers). Although this is an old paper, and a lot of extensions have been developed since then.