5 ms·

We abandoned it due to lack of ecosystem support. We originally picked it for general ETL / analytics / preprocessing data viz when opencl vs. nvidia for commo

We abandoned it due to lack of ecosystem support. We originally picked it for general ETL / analytics / preprocessing data viz when opencl vs. nvidia for commodity data parallel hardware ( = GPU ) was unclear, and as a long option in case FGPAs would ultimately make sense. But the CUDA software stack's community + Nvidia investments eventually converted us. Interestingly, we now exclusively use high-level data parallel abstractions like RAPIDS dataframes, so if there was say a Modin->risc-v path, wouldn't be too heavy a lift to port most of our stack. (Though, as is, little reason to.)

zozbot234 7y ago
The ecosystem seems to be moving to Vulkan-based compute these days. That's more aligned to the hardware than plain old OpenCL, so performance should be improved.
- lmeyerov 7y ago
  Not sure what hw support adds here. While I prefer stacks that a megacorp doesn't own at the bottom, my point is it's the software. Current langs + frameworks are relegated to a tiny fragment of the coding population. So more about making it as easy to reach for GPU / data parallel stuff as folks do for say Spark or Pandas. We tried working with AMD & Intel early on here but they didn't really get it (architects, investors, and a few other decision-maker-types). It's easy to put $10-20M into the ecosystem and just build it -- a16z finally has several years after we pitched it to them, and so did Nvidia with rapids.ai after we pushed them for a couple years ("what's a dataframe?"). Nothing stopping AMD/Intel and other opencl ecosystem players. But they still aren't.
- Athas 7y ago
  I don't think this is true, or at least as simple a story as "Vulkan is faster". OpenCL is already a pretty good and modern API, and computation in Vulkan doesn't seem like it's the main point. It's my impression that Vulkan is mostly fast compared to OpenGL, and particularly by removing driver overheads, but that has never really been a big problem with OpenCL. Last year, I had a student add a Vulkan backend to a GPU-targeting compiler[0]. Compared to the OpenCL backend, many programs ran substantially slower, and very few ran faster. It's certainly possible that this backend is imperfect, but it's more of a data point that I have seen elsewhere. [0]: https://futhark-lang.org/student-projects/steffen-msc-project.pdf https://futhark-lang.org/student-projects/steffen-msc-projec...

zozbot234 7y ago

The ecosystem seems to be moving to Vulkan-based compute these days. That's more aligned to the hardware than plain old OpenCL, so performance should be improved.

lmeyerov 7y ago
Not sure what hw support adds here. While I prefer stacks that a megacorp doesn't own at the bottom, my point is it's the software. Current langs + frameworks are relegated to a tiny fragment of the coding population. So more about making it as easy to reach for GPU / data parallel stuff as folks do for say Spark or Pandas. We tried working with AMD & Intel early on here but they didn't really get it (architects, investors, and a few other decision-maker-types). It's easy to put $10-20M into the ecosystem and just build it -- a16z finally has several years after we pitched it to them, and so did Nvidia with rapids.ai after we pushed them for a couple years ("what's a dataframe?"). Nothing stopping AMD/Intel and other opencl ecosystem players. But they still aren't.
Athas 7y ago
I don't think this is true, or at least as simple a story as "Vulkan is faster". OpenCL is already a pretty good and modern API, and computation in Vulkan doesn't seem like it's the main point. It's my impression that Vulkan is mostly fast compared to OpenGL, and particularly by removing driver overheads, but that has never really been a big problem with OpenCL. Last year, I had a student add a Vulkan backend to a GPU-targeting compiler[0]. Compared to the OpenCL backend, many programs ran substantially slower, and very few ran faster. It's certainly possible that this backend is imperfect, but it's more of a data point that I have seen elsewhere. [0]: https://futhark-lang.org/student-projects/steffen-msc-project.pdf https://futhark-lang.org/student-projects/steffen-msc-projec...