[HN Gopher] Vortex: OpenCL compatible RISC-V GPGPU
___________________________________________________________________
Vortex: OpenCL compatible RISC-V GPGPU
Author : hasheddan
Score : 96 points
Date : 2024-04-11 16:19 UTC (6 hours ago)
(HTM) web link (vortex.cc.gatech.edu)
(TXT) w3m dump (vortex.cc.gatech.edu)
| pixelpoet wrote:
| OpenCL is the best damn compute API ever. I'd totally buy and use
| one of these GPUs if I could!
| IshKebab wrote:
| Really? I found it to be much worse than CUDA when I tried to
| use it years ago.
| wubrr wrote:
| In what ways was it better/worse?
| softfalcon wrote:
| Having used both, it is true that CUDA has the "enterprise
| edge" of being a proprietary, paid for product, backed by an
| (almost) trillion dollar company. There are features and
| conveniences in CUDA that aren't present in OpenCL.
|
| That being said though, for how little funding, research, and
| support OpenCL receives, it is an astoundingly capable tool.
|
| I don't think it's fair to compare apples and oranges, even
| if they're clearly both "fruit" with a "high sugar content".
| pjmlp wrote:
| It isn't as if the Intel and AMD enterprises ever managed
| to produce anything comparable to CUDA tooling.
| seanw444 wrote:
| Nvidia has brand recognition and momentum on their side.
| It's not that Apple or AMD are incapable.
| pjmlp wrote:
| AMD has more than proven its incapability to provide
| proper OpenCL tooling during the last 10 years.
|
| Apple gave up on OpenCL, after disagreements how Khronos
| managed it.
|
| Metal Compute provides a CUDA like development
| experience.
| smallmancontrov wrote:
| NVidia's OpenCL was fine, but AMD's OpenCL was an unholy
| dumpster fire of broken examples, missing error messages, and
| crashing drivers.
| MaxBarraclough wrote:
| I used OpenCL a little in 2015. AMD's implementation seemed
| pretty good, whereas nVidia's was significantly behind. It
| didn't support OpenCL 1.2, iirc.
| pjmlp wrote:
| I guess, if one enjoys using C99 without any kind of nice
| tooling, calling GPU compiler and linker with APIs, printf
| debugging.
| pixelpoet wrote:
| Indeed, I'm not a fan of C++28 with virtual functions,
| exceptions, new/delete and whatever in my GPU code :P
|
| With a parallel CPU implementation I have pretty few
| debugging issues, and most importantly, I definitely enjoy
| having excellent performance on Intel, AMD and Nvidia GPUs,
| on Windows, Mac and Linux.
| WanderPanda wrote:
| Templates would be nice, though. So much better than macros
| mdaniel wrote:
| there have been quite a few threads about "reasonably priced"
| FPGA platforms and
| https://github.com/vortexgpgpu/vortex/blob/master/docs/fpga_...
| will interest you, but regrettably I haven't ever tried to use
| an FPGA to speak to whether their verilog only targets _one_ of
| them, or "bring your own," and for sure I'm not the right
| person to speak to how much such a stunt would cost
|
| It would make for a helluva blog post, though, or set up a
| shopify selling pre-made ones for people like you :-)
| lenerdenator wrote:
| I'm excited for what processors and software look like in 5-10
| years. Open all the way down.
| SpecialCoffee wrote:
| Could we get an expert to weigh in on the state of OpenCL. It
| seems like AMD and Intel are shifting away from OpenCL other
| GPGPU languages such as ROCm and DPC++.
| pjmlp wrote:
| DPC++ is Intel's own thing on top of SYCL, which relies on
| OpenCL drivers, basically long story short, what happened after
| Khronos realized shipping source code and C99 dialect wasn't
| really what most researchers were keen on using for their work.
| pixelpoet wrote:
| Not sure if having two commercial OpenCL apps[0] makes me an
| expert, but the practical reality is that OpenCL works just
| great today, even on latest Apple platforms. It's not a lot of
| work to do a little testing and tuning on the 3 main vendors.
| News of OpenCL's demise is greatly exaggerated.
|
| [0] https://glaretechnologies.com/
| rwbt wrote:
| What version of OpenCL do Apple platforms support? Also, is
| OpenCL also deprecated like OpenGL on Apple?
| my123 wrote:
| it's 1.2, macOS only, and marked as deprecated
| jsheard wrote:
| Did you figure out a way to interop OptiX with OpenCL, or do
| you just not use Nvidias RT acceleration? AFAIK it's not
| exposed directly through OpenCL.
| VHRanger wrote:
| People are moving away from OpenCL. The big problem is driver
| support. The transition from 2 to 3 was a mess, performance is
| all over the place on some functions between intel/amd/nvidia,
| and Apple is at the point of just leaving it out.
|
| People have even started using Vulkan in its place for some
| GPGPU, because at least Vulkan has good drivers everywhere,
| being a low-level API.
| keldaris wrote:
| While this is completely true, it is also true that OpenCL
| 1.2 is the one compute API that just works on every major
| platform and the drivers don't seem that unusably bad (though
| I'm not claiming experience of every platform here, just
| Nvidia on Windows/Linux and Apple Silicon on MacOS). Writing
| a limited dialect of C and sticking to 1.2 limitations is far
| from ideal, but it does at least work reliably. Sadly, that
| is more than can be said about most competitors.
| VHRanger wrote:
| Yes, 1.2 is OK.
|
| The problem is that the drivers are merely OK. Presumably
| if you're using OpenCL you care about the performance
| (otherwise why would you??) and since that's the case, it's
| the best on no platforms, and there are alternatives for
| any set of platforms that do better.
|
| I think OpenCL is sadly on its way out, and it's mostly
| Apple's fault (and Nvidia a little). Vulkan compute is much
| more interesting if you're looking to leverage
| iGPUs/mobile/other random CPUs.
|
| If you're targetting workstations/server workloads only, it
| makes sense to restrict yourself to a subset of accelerator
| types and code for that (eg. Torch or JAX for GPUs, use
| highway for SIMD, etc.)
| pvg wrote:
| A thread from 2020: https://news.ycombinator.com/item?id=22492902
| m3kw9 wrote:
| So why need Wikipedia when this model can get me any topic I
| want?
| taminka wrote:
| to clarify, this is a gpgpu lib implementation that's compliant
| to the openCL spec, right?
|
| i imagine if i tried to explain to someone the state of modern
| GPU computing i'd sound like an insane person, why is it so
| complicated, ugh :(
|
| so there's openGL and openCL, which are specifications with
| various implementations, both widely supported, but not as
| performant/modern
|
| there are vulkan/metal/dx, which are all modern with good driver
| support (metal limited driver support) graphics-first APIs, with
| compute shaders (vulkan kompute, metal performance shaders and
| whatever dx has?), all three have excellent performance
|
| then there is cuda/hip, both of which are proprietary, cuda w/
| excellent driver support, and hip w/ reportedly awful driver
| support, cuda can only target nvidia gpus, and hip can target
| both cuda and amd gpus (though very few amd gpus), both have very
| good performance
|
| then there is SYCL, which is by khronos, and it's what intel uses
| w/ openAPI, which is a heterogenous computing framework that can
| produce openCL/vulkan and in the future other api's code
|
| then there's webgpu, which is a spec, that has two C and one rust
| implementations, that can target all of the above (except SYCL
| obv, bc it's not a graphics api)
|
| did i get that right?
___________________________________________________________________
(page generated 2024-04-11 23:00 UTC)