I fail to see how scale is not just another form of vendor lock in, given that their compiler is not open source. Every compiler used today except cuda's is open source. And Nvidia can get away with it because no one else cares about development experience
Alternative(s) to run CUDA on non-Nvidia hardware
61–70 of 82 posts
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#62Earlier quoted context omitted.
If you think changing to Vulkan 1.4 solves all the problems, you clearly aren't writing cross platform code. First of all, that isn't even a thing if you need to target Android, or embedded hardware, secondly there are other extensions on the horizon.
The vast majority of vulkan usecases aren't android or embedded. I indeed wouldn't recommend it there.
Without Android and embedded, its market is mostly SteamaDeck and some universities for the most part.
Nintendo, PlayStation, Apple and Microsoft have their own APIs.
Visualisation industry is still largely on OpenGL, when not using middleware that uses each platform proprietary API, or moving into compute like CUDA as OTOY has done.
Khronos had to come up with ANARI, to convince them to even think about Vulkan in first place.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#63Earlier quoted context omitted.
It's quite easy to set up a light abstraction layer with Vulkan where you simply use VMA, buffer device addresses and push constants for everything. No descriptor sets or bindings anything. Alternatively you can use one of many abstraction layers that do this for you.
It absolutely isn't. After having spent 5 days not getting anything done in Vulkan, and being able to implement that same thing in a single day in Cuda (no prior experience in either API), I decided to never ever use Vulkan. It's a hopelessly overengineered API that is in dire need of a successor. I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-lin…
Skill issue. Vulkan is intended to be unopinionated around those things. If you want defaults then use a wrapper.
P.s. devices and queues are generally ordered for simple programs you can just pick the 1st one.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#64Earlier quoted context omitted.
We're actually targeting all of it, and not just CUDA C++.
How do you deal with target-specific inline asm like tcgen05.mma?
We haven’t yet released support for tcgen05, but we’ll deal with it the same way we deal with other inline PTX: parsing it and converting it to target-appropriate instructions together with the rest of the program.
This is something we’ve done already for the hopper-class tensorcore instructions, and the blackwell ones will map similarly, though likely with a kernel launch involved.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#65Earlier quoted context omitted.
It absolutely isn't. After having spent 5 days not getting anything done in Vulkan, and being able to implement that same thing in a single day in Cuda (no prior experience in either API), I decided to never ever use Vulkan. It's a hopelessly overengineered API that is in dire need of a successor. I may give it another try once it does not require a wrapper before it is remotely usable. I.e., once it has a single-lin…
Skill issue. Vulkan is intended to be unopinionated around those things. If you want defaults then use a wrapper. P.s. devices and queues are generally ordered for simple programs you can just pick the 1st one.
Of course it is a skill issue, I'm not afraid of admitting I'm not smart enough for Vulkan. That so many people have skill issues is the reason why Cuda trumps and will continue to trump Vulkan despite being vendor-locked. If you want people to actually use Vulkan, you need to remove barriers to skill-issued people like me. Poor third party wrappers like VMA that barely address one out of hundreds of issues aren't going to accomplish that, you need to resolve barriers in the core API. With a design like Cuda where there is always a default easy path, and a complex but optional path.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#66Earlier quoted context omitted.
Peanut-gallery is happily using CUDA, and needs actual sound reasons to move.
Then the peanut gallery has nothing to complain when Nvidia jacks up prices.
They don't though. Money for ai is pretty much free in America to anyone who can demonstrate a modicum of competence in the field.
The only people who are without access are students or hobbyists really.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#67Earlier quoted context omitted.
Then the peanut gallery has nothing to complain when Nvidia jacks up prices.
Do you see me complaining? Here is a tip, you don't always need to suffer from FOMO and get the very latest model card. In fact, contrary to the competition, one can play with CUDA even on laptops, go figure.
> In fact, contrary to the competition, one can play with CUDA even on laptops, go figure.
This is the part people don't get. You can program cuda anywhere on any Nvidia card, unlike other companies' chips you don't need a data center gpu to have full programmability. It's been this way for over a decade
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#68There's nothing wrong to run CUDA on non-Nvidia hardware. CUDA has an interface that is reasonably well-designed, well-documented/reverse-engineered, and battle-tested for decades. What we need is not to invent another interface just under the name of 'open standard', but to implement the same interface. ROCm is exactly doing this, and so are other hardware SDKs such as MooreThread and Alibaba T-Head.
So is Spectral, which is mentioned in the headline of the article! As it says there:
> SCALE delivers nearly a 6x performance boost on AMD GPUs compared to using HIPIFY to convert CUDA code to AMD’s own ROCm environment
... whilst also running CUDA.
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#69Earlier quoted context omitted.
The vast majority of vulkan usecases aren't android or embedded. I indeed wouldn't recommend it there.
Without Android and embedded, its market is mostly SteamaDeck and some universities for the most part. Nintendo, PlayStation, Apple and Microsoft have their own APIs. Visualisation industry is still largely on OpenGL, when not using middleware that uses each platform proprietary API, or moving into compute like CUDA as OTOY has done. Khronos had to come up with ANARI, to convince them to even think about Vulkan in fi…
Moving the goalposts much? Linux and Microsoft is still a huge market. Ii don't know about the switch 2 but the switch 1 had vulkan support. Apple as well if you count moltenvk
Re: Alternative(s) to run CUDA on non-Nvidia hardware
#70Earlier quoted context omitted.
Without Android and embedded, its market is mostly SteamaDeck and some universities for the most part. Nintendo, PlayStation, Apple and Microsoft have their own APIs. Visualisation industry is still largely on OpenGL, when not using middleware that uses each platform proprietary API, or moving into compute like CUDA as OTOY has done. Khronos had to come up with ANARI, to convince them to even think about Vulkan in fi…
Moving the goalposts much? Linux and Microsoft is still a huge market. Ii don't know about the switch 2 but the switch 1 had vulkan support. Apple as well if you count moltenvk
Not at all, I mentioned where Vulkan actually has a market, and why using Vulkan 1.4 is not the solution you think it is.
There is hardly any commercial Vulkan market on Windows, with exception of tools like Autodesk VRED or Disney Hyperion, hardly every man tools and the reason one might use desktop Linux for 3D rendering instead, with proprietary drivers anyway. As a user, not developer.
List of commercial games on Windows using Vulkan, without having a DirectX 12 backend as option is pretty thin.