Add generic support for OpenCL #251
Comments
|
Put energy into Vulkan since OpenCL is defunct? Khronos says so themselves? |
|
Firstly, Vulkan is a graphics API and OpenCL is a compute API.
Secondly, OpenCL will be around for a while and Vulkan support is nonexistant at the
moment on the platforms I am interested in.
Also where did you read that? A quick Google returns an article dated 2nd Jan 2019 saying OpenCL will continue to evolve as well.
…On Mon, 22 Apr 2019, 12:12 Tony Butler, ***@***.***> wrote:
Put energy into Vulkan since OpenCL is defunct? Khronos says so themselves?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGL3HEG2KAKJLHXFDXRTUTPRWMRVANCNFSM4HDZQ5CA>
.
|
|
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. |
|
Also this, which is a year old so I figured RPi would have it too by now. |
|
That was what I was trying to get xmrig to use.
Additionally the first benchmarks for the Pi4 are out giving between 2x
faster for GPU and 4x faster for neon.
Unfortunately AES appears not to be baked into silicon (unlike the Nano).
I have yet to pick up a Pi4 - just waiting for case manufacturers to catch
up but I will get one when they do.
GR
…On Thu, 27 Jun 2019, 05:34 Tony Butler, ***@***.***> wrote:
Also this
<https://www.phoronix.com/scan.php?page=news_item&px=Raspberry-Pi-Vulkan-Code-Drop>,
which is a year old so I figured RPi would have it too by now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#251?email_source=notifications&email_token=ABGL3HFA3TBFQINBVID5LALP4Q7OZA5CNFSM4HDZQ5CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYVUTXQ#issuecomment-506153438>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGL3HDMJZAJOLPWKRUSLHLP4Q7OZANCNFSM4HDZQ5CA>
.
|
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.
The text was updated successfully, but these errors were encountered: