Comment by taminka | Hacker News Reader

Comment by taminka | Hacker News Reader

Parent Full thread

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?

CPU side took a very long time to pare down the fragmentation. For the first ~50 years there were competing proprietary instruction sets and software stacks, languages and compilers and operating systems were vendor specific, buggy and mutually incompatible. Compilers were sold separately and expensive, apps were platform specific. x86 would have remained a monopoly if not for a licensing accident with Intel second-sourcing chips from AMD.

We're seeing a version of that replaying, with some parts better and some parts worse.

The GPU situation would be ripe for regulation to lift GPU software development from the dark ages, but companies who benefit most (NVidia) have probably become too big to regulate.

> too big to regulate.

I guess you are from the US and not EU? It's when they get too big and abuse their monopoly they will be regulated.

AFAIK nvidia have not done anything to abuse its power yet, but its hard for big companies to not use their monopoly in a illegal way since its always a good a Market strategy just illegal

interesting, hopefully same homonegisation will happen to gpu sphere as well :)

> 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 :(

I mean, do you think this is different for anything else in our field? This was in some sense really simple... try doing this for front-end GUI frameworks or even multi-tenant isolation technologies.

my point of comparison is other types of accelerators (CPUs mostly) and GPU ecosystem in the past (when there was just like openCL and openGL)

I would add WebGL to the mix, for when you need that GPU performance in a browser that doesn't support WebGPU yet..

You missed GNM/GNMX, GX/GX2/NVN from Sony and Nintendo respectively, which tend to be forgotten on 3D API discussions.

That's because very few people have access to them and there's no information about them in the open.

Rather the urban myth that they fully support Khronos APIs persists.

To be fair there was some kind of support on the PS3 with GL ES 1.0/Cg shaders as secondary API, later dropped, Wii GX(2) shaders are based on GLSL, and while Switch does support GL 4.6 and Vulkan for porting purposes, it is either Nintendo extensions spaghetti time, or rewrite in NVN, for actually taking full advantage of the hardware.

mlx: a mix between numpy and cuda/hip for metal

You missed ROCm?

ROCm is a whole ecosystem. HIP falls under ROCm.

Reply on news.ycombinator.com