Live data from Hacker News

VUDA: A Vulkan Implementation of CUDA

github.com

51–60 of 83 posts

Re: VUDA: A Vulkan Implementation of CUDA

#51
post #44
post #27

Earlier quoted context omitted.

I've had the opposite experience under Linux. My old nvidia 570's drivers went into severe bitrot. Basic stuff like screensavers and desktops broke badly, and games were flaky. The card is still more than powerful enough for what I used it for. I switched to AMD, with open source drivers. I get windows-level performance on AAA (and indie) games in steam, and zero compatibility issues with the rest of the Linux ecosys…

AMD GPU support in linux is a bit of a flip flop. Some generations seem to get a lot of love and work really damn well (sometimes with better and broader support than the windows drivers) like RDNA2 and most Polaris cards. Others such as Vega and specially now RDNA3 are a shitshow with a lot of things just broken.

I ran vega 64 in linux for 3-4 years, it was really nice. It also worked without bugs with proton, the 3060 I have now gives me a lot of artifacts like incorrect lightning and even X crashes once in a while.

I'm considering switching back to an AMD card due to this.

Re: VUDA: A Vulkan Implementation of CUDA

#52
post #48
post #27

Earlier quoted context omitted.

I've had the opposite experience under Linux. My old nvidia 570's drivers went into severe bitrot. Basic stuff like screensavers and desktops broke badly, and games were flaky. The card is still more than powerful enough for what I used it for. I switched to AMD, with open source drivers. I get windows-level performance on AAA (and indie) games in steam, and zero compatibility issues with the rest of the Linux ecosys…

Why are you talking about screensavers in a CUDA thread though? You can't compute on a fancy screensaver animation, you need a working CUDA driver that nVidia provides for that.

Likely because this subsection of the thread seems more focused on drivers in general and less on CUDA, if the other replies are anything to go by.

Re: VUDA: A Vulkan Implementation of CUDA

#53
post #11

How does this relate to the goals outlined by George Hotz to bring ML to AMD chips and break the Nvidia dominance? I'm not an expert here but this approach seems powerful and important. But this system seems complex enough to doubt the ability of an individual to build. It seems like this would need a corporate sponsor to get off the ground. Perhaps AMD itself would be interested in paying engineers to iterate on thi…

Holtz is talking about drivers too, not just user space libraries. > The software is terrible! There’s kernel panics in the driver. You have to run a newer kernel than the Ubuntu default to make it remotely stable. I’m still not sure if the driver supports putting two cards in one machine, or if there’s some poorly written global state. When I put the second card in and run an OpenCL program, half the time it kernel…

The only hope is rusticl and it happens inspite of AMD.

Re: VUDA: A Vulkan Implementation of CUDA

#54

Just in case other people who have AMD GPU and run Windows have the same needs as I have, that is, to train or run machine learning models, please checkout torch-directml and tensorflow-directml.

How does it work? Last time I tried DirectML it wasn't well supposed and there was little software which supported it. Also the performance seemed to be not too great. I am currently using a Linux install because with ROCm I can use popular tools like Automatic111 webui and oobabooga.

Re: VUDA: A Vulkan Implementation of CUDA

#55

It's not an implementation of CUDA, it's an implementation of the CUDA runtime API. The API is used to configure the card, allocate and copy memory, and run kernels. Importantly you cannot use this to write the actual kernels which run on the GPU!

I was half hoping this meant running CUDA code on AMD GPUs. Thanks for clarifying.

Shameless plug: https://www.osti.gov/servlets/purl/1892137

TLDR; If you provide even more functions through the overloaded headers, incl. "hidden ones", e.g., `__cudaPushCallConfiguration`, you can use LLVM/Clang as a CUDA compiler and target AMD GPUs, the host, and soon GPUs of two other manufacturers.

Re: VUDA: A Vulkan Implementation of CUDA

#56
post #34

Earlier quoted context omitted.

I know AMD has a whole bunch of (related?) projects for GPU compute, but man - if they could just provide an interop layer that Just Works they'd get immediate access to so much more market share.

Eh well, it is very close to just working. From "Training LLMs with AMD MI250 GPUs and MosaicML": > It all just works. No code changes were needed. https://www.mosaicml.com/blog/amd-mi250

“Just works” in this context means executing the compiled CUDA or the PTX bytecode without recompiling. Nobody is ever going to utilize ROCm if it requires distributing as source and recompiling.

To make it even more insulting, even simply installing ROCm itself is a massive burden, even on an ostensibly-supported (as geohot discovered) and even just “it works out of the box if you distribute and compile it locally” is ignoring that whole massive “draw the rest of the owl” stage of getting ROCm installed and building properly in your environment.

Re: VUDA: A Vulkan Implementation of CUDA

#57
post #35

Earlier quoted context omitted.

I know AMD has a whole bunch of (related?) projects for GPU compute, but man - if they could just provide an interop layer that Just Works they'd get immediate access to so much more market share.

It is coming from what I can tell

It's been coming for years now. I will probably be years before it really is here.

Re: VUDA: A Vulkan Implementation of CUDA

#58

1. This implements the clunky C-ish API; there's also the Modern-C++ API wrappers, with automatic error checking, RAII resource control etc.; see: https://github.com/eyalroz/cuda-api-wrappers (due disclosure: I'm the author) 2. Implementing the _runtime_ API is not the right choice; it's important to implement the _driver_ API, otherwise you can't isolate contexts, dynamically add newly-compiled JIT kernels via modul…

nice project. this is why HN kicks ass

Re: VUDA: A Vulkan Implementation of CUDA

#59
post #56
post #34

Earlier quoted context omitted.

Eh well, it is very close to just working. From "Training LLMs with AMD MI250 GPUs and MosaicML": > It all just works. No code changes were needed. https://www.mosaicml.com/blog/amd-mi250

“Just works” in this context means executing the compiled CUDA or the PTX bytecode without recompiling. Nobody is ever going to utilize ROCm if it requires distributing as source and recompiling. To make it even more insulting, even simply installing ROCm itself is a massive burden, even on an ostensibly-supported (as geohot discovered) and even just “it works out of the box if you distribute and compile it locally”…

Don't forget AMD doesn't seem to even care about ROCm themselves. Six months in and RDNA3 cards still don't support it. Can you imagine if Nvidia launched RTX40- cards with no DLSS even though 30- cards already had it, and six months started boasting about how DLSS support was "coming this fall"?

Re: VUDA: A Vulkan Implementation of CUDA

#60
post #44
post #27

Earlier quoted context omitted.

I've had the opposite experience under Linux. My old nvidia 570's drivers went into severe bitrot. Basic stuff like screensavers and desktops broke badly, and games were flaky. The card is still more than powerful enough for what I used it for. I switched to AMD, with open source drivers. I get windows-level performance on AAA (and indie) games in steam, and zero compatibility issues with the rest of the Linux ecosys…

AMD GPU support in linux is a bit of a flip flop. Some generations seem to get a lot of love and work really damn well (sometimes with better and broader support than the windows drivers) like RDNA2 and most Polaris cards. Others such as Vega and specially now RDNA3 are a shitshow with a lot of things just broken.

I used a Vega64 for years and just bought a 6000 series. Both work great on my machines. I'm typically running the bleeding edge kernels though, so that might explain it a bit. I would think Ubuntu is probably the most supported if you opt for the OEM kernel.
Post reply on HN