Add generic support for OpenCL
grahamreeds opened this issue · 6 comments
If Apple does jump ship to Arm then AMD won't be the only OpenCL fruit.
The Raspberry Pi seems to be moving towards an implementation of OpenCL (https://github.com/doe300/VC4CL).
I have looked at porting it across: For 2.8.3 I got it compiling cleanly on a RaspPi but the AMD specifics were a drag. I have tried again with 2.14.1 but there is a large change to the number of parameters that various functions take. I fixed the number of parameters (but not the internals) but ran into linker issues a couple of nights back.
Put energy into Vulkan since OpenCL is defunct? Khronos says so themselves?
Of course I can't find the original Khronos document (on LunarG site) regarding how Vulkan Compute was about to pwn-all-everythings. I suppose since OpenCL is also a Khronos endeavor, themselves saying Vulkan Compute Owns The World made me assume that includes (especially?) OpenCL, because both things are going to talk SPIR-V (OpenCL 2.1) so really then OpenCL is just the enqueue conveyor, and at doing that it kind of sucks. It made it seem like OpenCL 2.1 would be a wrapper around the real guts, Vulkan Compute (which was the first thing I heard of using SPIR-V). It was about a week before Apple announced they were dropping OpenCL support in upcoming OSX, and about years after nvidia stopped bothering to improve their OpenCL support (which remains slower and clunkier by far than CUDA).
This seems to sum it up more or less, but I wish I could find the original FAQ entry or press release because it definitely said OpenCL should die off and be replaced by Vulkan Compute. Perhaps LunarG tempered the "replacement" statement since then as now it seems they added on "if your application uses OpenCL for graphical output" but I don't think that means never use it for compute if you aren't using the output for graphics. It appears to have better repetitive-work queue supports like CommandBuffers and does fewer PCIe transfers when used properly. However as of now it might be missing some precision in how it does some operations as they are focused on "close enough for visual display" and not on "exact to the millionths" so it may not work for mining kernels (yet!) but should be the preferred method for shoveling work to a GPU as it is only for GPU work.
OpenCL is for nerd goober science analysis, and AI and computer vision, and tons of things, but it's not really best for mining on GPUs, and has never been better than native miners on CPUs, so then why use a generic compute-API when we really want to compute on GPUs or not at all. OpenCL was used for mining because it was available at the time, it is by far not the best method it was just the only method.
Now we have a split because OpenCL-on-nvidia sucks and is still 1.2 and even when everyone else was still 1.2 also, it was still slower, so any nvidia miners have to be CUDA or not bother. AMD went ahead with 2.0 and beyond, but also added their own nonstandard extensions, and so if you want an AMD miner it's got to be OpenCL 2.0+amd or not bother.
But Vulkan really seems to have the support of both so it sure seems like the unified place to go forward.