I'm really hoping Modular.ai takes off. GPU programming seems like a nightmare, I'm not surprised they felt the need to build an entire new language to tackle that bog.
mirsadm•3h ago
GPU programming isn't really that bad. I am a bit skeptical this is the way to solve it. The issue is that details do matter when you're writing stuff on the GPU. How much shared memory are you using? How is it scheduled? Is it better to inline or run multiple passes etc. Halide is the closest I think.
solarmist•2h ago
What are you skeptical of? I believe the problem this is solving is a framework that's not CUDA that allows low level access to the hardware, makes it easy to write kernels, and is not Nvidia only. If you watch the video you can write directly in asm if you need to. You have full control if you want it. But it provides primitives and higher level objects that handle common cases.
I'm a novice in the area, but Chris is well respected in this area and cares a lot of about performance.
pjmlp•2h ago
There are already plenty of languages in CUDA world, that is one reasons it is favoured.
The problem isn't the language, rather how to design the data structures and algorithms for GPUs.
solarmist•2h ago
Not sure I fully understand your comment, but I'm pretty sure the talk addresses exactly that.
The primitives and pre-coded kernels provided by CUDA (it solves for the most common scenarios first and foremost) is what's holding things back and in order to get those algorithms and data structures down to the hardware level you need something flexible that can talk directly to the hardware.
pjmlp•1h ago
C, C++, Fortran, Python JIT from NVidia, plus Haskell, .NET, Java, Futuhark, Julia from third parties, and anything else that can bother to create a backend targeting PTX, NVVM IR, or now cuTile.
The pre-coded kernels help a lot, but you don't have to use them necessarly.
diabllicseagull•2h ago
It is a noble cause. I've spent ten years of my life using CUDA professionally, outside the AI domain mind you. Most of these years, there was a strong desire to break off of CUDA and the associated Nvidia tax on our customers. But one thing we didn't want was to move from depending on CUDA to depending on another intermediary which would also mean financial drain, like the enterprise licensing these folks want to use. Sadly, open source alternatives weren't fostering much confidence, either with their limited feature coverage or just not knowing if they will be supported in the long term (support for new hardware, fixes, etc.).
catapart•2h ago
My mistake completely, but I thought this was going to be something to do with a new scheme or re-thinking of graphics programming APIs, like Metal, Vulkan or OpenGL. Now I'm kind of bummed that it is what it is, because I got really excited for it to be that other thing. =(
pjmlp•2h ago
That is already taking place with work graphs, and making shader languages more C++ like.
ttoinou•2h ago
Seems like with it you will be able to compile and execute one code on multiple GPU targets though
ashvardanian•2h ago
There is a "hush-hush open secret" between minutes 31 and 33 of the video :)
refulgentis•1h ago
TL;Dr same binary runs on Nvidia and ATI today, but not announced yet
throwaway314155•2h ago
They desperately need to disable whatever noise cancellation they're using on the audio. Keeps cutting out, sounds terrible.
solarmist•3h ago
mirsadm•3h ago
solarmist•2h ago
I'm a novice in the area, but Chris is well respected in this area and cares a lot of about performance.
pjmlp•2h ago
The problem isn't the language, rather how to design the data structures and algorithms for GPUs.
solarmist•2h ago
The primitives and pre-coded kernels provided by CUDA (it solves for the most common scenarios first and foremost) is what's holding things back and in order to get those algorithms and data structures down to the hardware level you need something flexible that can talk directly to the hardware.
pjmlp•1h ago
The pre-coded kernels help a lot, but you don't have to use them necessarly.