Rendered at 05:53:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
harhargange 6 minutes ago [-]
If anyone has used this, how good is this? And will it allow running AMD GPU with MATLAB? I have a 7900xt
linuxhansl 13 hours ago [-]
Off-topic and somewhat of a rant, but I'd far prefer us all focusing on open standards like HIP, SYCL, OpenCL, etc.
It's unbearable that most LLM inference happens on closed H/W, closed drivers, and closed SDKs.
mistercow 12 hours ago [-]
On the SDK front, you tried just having an agent reimplement the model you're interested in and just use the weights? I've taken to treating off the shelf implementations as reference implementations anyway, because I can often squeeze out significantly better performance for my configuration and use case by having Codex hammer at it for a few hours.
sroussey 12 hours ago [-]
Hugging face is working on something like this where well known models get fused into a single implementation.
drivebyhooting 12 hours ago [-]
Could you share the prompts and workflow? I’ve tried this too, but with mixed success when it comes to creating custom tile kernels.
I would really appreciate your input!
mistercow 12 hours ago [-]
It's been pretty ad hoc, but my prompts are nothing special. Things I generally do:
1. Top end model on high/xhigh thinking (last time I did it it was Sol xhigh I think)
2. Make sure it creates some representative fixtures of different sizes and sets up a good testing, profiling and benchmarking loop that doesn't require my input.
3. Make sure it has access to reference implementation code
Edit: Oh and one obvious pitfall that for some reason I still have to remind even smart models of from time to time: make sure it knows not to try to parallelize its benchmark runs. I've occasionally had an agent struggle to figure out absolutely nonsensical data because it tried to run multiple tests on the same compute hardware simultaneously.
mschuetz 11 hours ago [-]
The problem with the open standards is that their dev UX is absolutely horrible. You can't neglect usability, and then be surprised that there are no users.
the__alchemist 9 hours ago [-]
This is at the core of the matter for me, and my knowledge is too weak to understand why this is the case. I don't enjoy the idea of relying on Nvidia's stack for GPU compute, but the alternatives I've tried (e.g. Vulkan compute) are higher friction to use. I am trying to reconcile why; Nvidia shouldn't have this moat.
My software is labeled "CPU only unless using an nVidia GPU". I would prefer to strikethrough "nVidia". Incidentally, this means no more Mac support.
swerner 8 hours ago [-]
Vulkan compute is not really designed or intended to be a CUDA competitor, its feature set is much more restricted, and Vulkan host side code is much more verbose than CUDA. OpenCL or SYCL are much closer in features to CUDA. I found that when using SYCL on Nvidia, debugging symbols etc can be passed through and you can use tools like NSight Compute to profile it as if it were CUDA.
throwdbaaway 6 hours ago [-]
I tried getting LLMs to add proper Vulkan support to ik_llama.cpp, which have very good support for CUDA and CPU. The models do an admirable job; they don't care much about poor DX.
Few problems I noticed:
* coopmat2 from nvidia is the classic embrace, extend, extinguish. No point to ask the models to translate from CUDA to coopmat2. Instead, the models can understand the existing CUDA and CPU kernels, and adapt them accordingly to non-nvidia devices.
* However, the standard API is also lacking. The models struggled to make prompt processing compute-bound on strix halo when the graph is complex. Upfront standard API might just be an evolution dead end.
my123 5 hours ago [-]
coopmat2 can be implemented by anybody non-nvidia. It's not EEE when the regular coopmat extension is not good enough to get good performance
throwdbaaway 4 hours ago [-]
On the other hand, despite my complain about the standard API, the models were able to come up with cooptmat1 kernels that run dsv4 flash faster than whatever the guys at antirez/ds4 can come up with using rocm, on a strix halo, with the added benefit that I can also pair the strix halo with an egpu to drastically speed things up.
throwdbaaway 5 hours ago [-]
From what I can tell, coopmat2 can get to about 75~90% of cuda performance on a single device, and there is no good way to do direct communication across devices. It is fair to say that nobody would replace cuda with coopmat2? That looks like a EEE project that can assigned to a couple of nvidia engineers, to fragment the ecosystem.
HeavyStorm 11 hours ago [-]
Commercially it's better to have AMD support CUDA which can help break Nvidia soft monopoly.
christopher8827 3 hours ago [-]
yeh - exactly.
Sucks like important libraries like Alphafold are locked into CUDA. Its ridiculous for researchers.
bigyabai 13 hours ago [-]
I would too, but sadly that's Khronos' job to organize, and they've had trouble getting American vendors to work together.
It's likely that CUDA will continue dominating until they put aside their differences. The current MLX/MPS/ROCm ecosystems are too fractured to threaten Nvidia.
To my knowledge, SPIR-V on Intel will stay, and be it only because it’s part of the OpenCL and Vulkan standards.
my123 11 hours ago [-]
Yeah talking about the (vendor-preferred) compute part here
Vulkan's SPIR-V dialect is substantially different from the OpenCL one, notably with the former having structured control flow. They're incompatible between each other.
swerner 10 hours ago [-]
Yes, unfortunately. Otherwise we could just implement all of SYCL and OpenCL on top of Vulkan and live happily ever after.
bigyabai 13 hours ago [-]
I'm talking about holistic efforts like OpenCL, and standards that would be equivalent to Nvidia's "Compute Capability" versioning.
The basic underlying tech can be agreed on, but Apple/AMD/Intel all have different GPU priorities that limit their ability to agree on a CUDA-adjacent hardware platform.
omcnoe 6 hours ago [-]
Ultimately AMD missed the most important boat with their woeful support for GPU compute. 10 years ago they needed to go all in and offer something to compete with CUDA - whether that was internal or something standard from Khronos. They just couldn't commit to it as a business, didn't have the vision.
Intel missed for a different reason - they didn't invest in the product space at all for decades. In terms of units they had the most market share (millions of Intel Integrated Graphics chips), but it wasn't seen as important. Bare minimum to render Windows and Office UI, nothing more.
swerner 12 hours ago [-]
What do you mean by holistic? SYCL is an open versioned standard that allows for vendor specific extensions. The problem is not that there isn’t a proper standard, the problem is that many hardware vendors - or software developers simply don’t want to adopt it.
Intel (via Codeplay) was handing it out on a silver platter - Nvidia on SYCL, full top chain, and people still wouldn’t want it.
bigyabai 12 hours ago [-]
Isn't OneAPI a good example of the problem, alongside Mojo/ONNX/TensorRT? The industry doesn't need a fifteenth competing standard. They need hardware buy-in.
By holistic, I mean hardware architecture cooperation. Nvidia can hold onto their lead forever if GPU designers fight over what a GPGPU hardware baseline looks like. The current ecosystem fragmentation is not competitive, and future fragmentation probably wouldn't work either. I think the fastest way to kill Nvidia would be a hardware consortium.
swerner 12 hours ago [-]
The problem with OneAPI is naming. It leads people to believe that is another competing standard where in fact is is simply just an implementation of a standard compliant SYCL compiler. If it just had been named “Intel SYCL compiler”, similar to the existing and accepted Intel OpenCL compiler, it would have been easier.
What would you expect the hardware consortium to coordinate on? Unified ISA?
my123 12 hours ago [-]
oneAPI is effectively an Intel-only platform not a standard.
Yes they have implementations on top of CUDA but they're maintained by... Intel. They didn't get buy-in for cross-vendor collaboration
swerner 11 hours ago [-]
They were maintained by Codeplay - paid for my Intel. Nvidia can make contributions anytime they want, and here is the problem: Nvidia does not want to. Until each vendor starts pitching in with contributing their backend to an open standard, you will have to rely on others doing it for them.
kiicia 10 hours ago [-]
it will only get worse now when hughingface was bough by nvidia, not immediately, but in span of year or years...
anon291 10 hours ago [-]
It's impossible to have an open standard. Hardware accelerators are nothing alike and have different perf characteristics. Each kernel is tuned to the hardware. The idea of writing a performant kernel in opencl is a fantasy.
Source: worked at a bunch of accelerator companies in the kernels or equivalent team. They're nothing alike.
swerner 10 hours ago [-]
For a performant portable language, we’d have to go to a higher level where you describe what to do and leave the how to do to the compiler. It would then need to be able to adjust memory layout, access patterns, data type choice to the underlying hardware. I’m not sure if this is possible to do reliably - the closest we have right now may in fact be highly detailed plain English descriptions of the algorithms fed to an LLM prompted to produce assembly.
anon291 9 hours ago [-]
It's not possible to do reliably. None of the models in current use today use any esoteric math. It's extremely easy to implement the math behind both the inference and learning of all modern models.
swerner 8 hours ago [-]
Not everything is AI and dot products of massive vectors, there are still applications that do other maths on GPUs
My thinking was rather that most of our current programming languages put memory layout fully into the programmer’s responsibility - I can think off hand of a language where the compiler makes performance decisions like whether your structure are SoA, AoS or SoAoS, what alignment, padding, strides and float types to use.
Automatic decisions about when to use cooperative loads through shared local mem versus gathers from global mem and hardware caches are also something that such a hypothetical compiler would have to make.
anon291 6 hours ago [-]
I mean if you don't care about perf, opencl does what you want, and exists today.
As for ai and matrix vector performance... I mean matrices are extremely useful across many domains. The hands off language that exists today is called blas. That's fine but won't lead to the best perf on any GPU today.
SoA and AoS data layouts are not even a worthwhile point of contention. Same with shared v global mem. Today's hardware has specialized memory depending on the operation. The hardware on these processors is so specialized as to make anything but first class support for the feature be completely pointless. If you look at Nvidia code that's open source even they will special case a lot of their chips. Literally if you want the best perf you write the kernel exactly for the exact chip. That's intra vendor .. you can only imagine inter vendor
swerner 12 hours ago [-]
AI will take down Nvidia’s moat. When it becomes trivial to translate CUDA/PTX to HIP, SYCL or Metal, CUDA is no longer the moat, it becomes the intermediate representation.
larodi 11 hours ago [-]
trivial to translate (or transpile) - okay. trivial to understand the result - not so much. trivial to then evolve it - hm... perhaps a different story. still, it seems very likely now, that such "quick rewrites" are viable, not sure if an open approach to them is viable. a newly born open project that was LLM-derived, and not by a credible author, which spans hundreds of files no human eye has ever looked at, can only work for a closed organization, but will never be trusted by the general audience... just like that.
threatripper 4 hours ago [-]
I don't see a hard reason. If it works it works. No hard need for a good, universal, and long lasting solution. At some point you just stack slop on top of slop and it works for your use case - and if it doesn't you'll slop it out yourself.
saagarjha 2 hours ago [-]
How do you know if it works? Not that "works" is different from "runs".
bayindirh 12 hours ago [-]
> When it becomes trivial to translate CUDA/PTX to HIP,...
ZLUDA is already doing that, no?
swerner 11 hours ago [-]
I don't think we're at a point yet where anyone would trust ZLUDA enough to ship commercial products that rely on it. I would be delighted though, if anyone can prove me wrong.
bayindirh 11 hours ago [-]
No, but we can go there. This is an open source project. Anyone can put some more effort behind it and push it further. It's improving, AFAICS.
Unfortunately, many of very good ideas end with “it’s open source, anyone can contribute” because very few actually do.
Keyframe 12 hours ago [-]
yeah yeah, "when" an often keyword with AI it seems. As Mr. E. Nigma put it - what always comes but never arrives? Meanwhile the moat deepens and it's build on inertia and laziness and Nvidia knows this really REALLY well.
swerner 10 hours ago [-]
Oh, absolutely. Nvidia is the modern day “nobody gets fired for buying IBM”. The reason we’re still using Unix is not because it’s the best, but because it had to much inertia to let any alternative become its successor. Similarly, C and HTML are maybe the most terrible yet extremely useful languages we have.
mathisfun123 12 hours ago [-]
i swear people who are outsiders here have only clickbait takes; if you've never had to ship GPU code professionally you should just not comment on these things.
the source language has never been the moat. Nvidia sells to hyperscalers. Hyperscalers have armies of kernel authors who have no issue translating shaders by hand (or now with claude). Nvidia's moat is (and will remain for the foreseeable future) the entire stack. you cannot fathom the pain and misery of working on literally any other stack. if you've never debugged a GPU synchronization error or kernel panic due to some GPU firmware bug or fought absolute shit profilers hunting for perf you really have no idea what you're talking about.
EDIT: i can't believe this really requires saying but graphics and compute are not the same domain at all. if you work in graphics for GPU but not compute then you are still way out of your depth commenting. to wit: graphics people do not (and cannot) write CUDA kernels/shaders.
swerner 12 hours ago [-]
If that is your standard, I do have an idea what I’m talking about.
mathisfun123 12 hours ago [-]
Ya? do tell us about your experience that leads you to believe mere translation is the bottleneck in the market...
swerner 11 hours ago [-]
I’m too old to participate in internet pissing contests.
mathisfun123 11 hours ago [-]
this isn't a "pissing contest"? you made a speculative claim in a public forum and i'm challenging your authority to make such a claim. a "pissing contest" would be if i had said i've shipped hundreds of thousands of lines of shader code into prod and thus you clearly have no idea what you're talking about because you haven't (which is also true).
swerner 11 hours ago [-]
I could post the GitHub URLs of all the shader code I wrote that’s running on countless GPUs right now, but what would it change? I’m still just a random guy on the internet with an opinion that happens to be different from your opinion.
You can simply disagree with me, regardless of my experience (or lack thereof).
mathisfun123 11 hours ago [-]
> You can simply disagree with me
that's exactly what i did and made an argument for why i think you're wrong. in response you provided exactly zero substantive remarks other than "i've written shaders" and then accused me of pissing.
also FYI it's clear from your profile that you've only worked on graphics (embree, blender, etc) and not compute. so i'll repeat: you're an outsider and you have absolutely no idea what you're talking about.
swerner 11 hours ago [-]
Outsider to what?
mathisfun123 11 hours ago [-]
to the domain you presume to have authority to comment on
swerner 10 hours ago [-]
What domain do you think I was talking about?
swerner 11 hours ago [-]
If it helps you at all:
“if you've never debugged a GPU synchronization error or kernel panic due to some GPU firmware bug or fought absolute shit profilers hunting for perf”
I have done all of those things. As part of my full time job, for years.
Now that we’ve put all of that aside, can we stop talking about me and go back to discussing moats? What do you think are top three things that are holding customers back from buying AMD GPUs instead of Nvidia GPUs?
I could be misremembering, but I think Jensen Huang himself once called CUDA or the CUDA ecosystem their moat, and it certainly seems to be accepted narrative in the tech press. They may be wrong there, and you sharing your first hand experience here would be helpful to many of us readers here.
anon291 10 hours ago [-]
amd consumer gpus don't support rocm. That is basically the entire reason for Nvidia dominance. All Nvidia cards support cuda even the crappy ones
noir_lord 5 hours ago [-]
That’s not strictly true, they officially support some of them.
My 7900XTX is supported, I run local models via rocm all the time recently, mostly to play with/experiment on, Vulcan works as well and for some models works better (or the trade offs are better for that use case).
Their mistake was simply not picking and going all in earlier, they let nvidia become the defacto standard without even contesting it on both the hardware side and software side and that’s a hard though not impossible comeback to make.
Long term I think they’ll catch up in capability if not market share because simply too much money on the table not to.
Most modern graphics is compute. Pixar, Dreamworks, Sony, etc do not use Vulkan to render their movies. It’s CPUs or CUDA.
“graphics people do not (and cannot) write CUDA kernels/shaders” is just not true at all. All it would take to verify that would be things like reading the introduction of the OptiX documentation, a small sample of SIGGRAPH GPU papers or the Blender/Cycles source code.
swerner 23 minutes ago [-]
Wait, I have an idea:
What is your qualification for talking about graphics programming? If you cannot provide credentials, I will have no other choice than to claim you don’t know what you’re talking about, based on the criteria by which you judged my comments so far.
triwats 7 hours ago [-]
Interesting option for CDNA architecture chips. I wonder if this moves to an open standard?
To save everyone a click: No cuDNN and based off an ancient version of ROCm for windows (7.1 has been out for ages, 7.2 is current.)
vivzkestrel 2 hours ago [-]
stupid question
- what exactly is CUDA?
- is it patented hardware tech that AMD cannot replicate?
- is it a library that ll also work on AMD while it currently works on nvidia
- can AMD cook an equivalent of CUDA, if so why havent they done it?
Nurysso 11 hours ago [-]
man i can't say how much i used to like cuda when i had a nvidia gpu it made ml so much fun and on amd its a war especially on rdna 2 cards which i have. hopefully one day we will be able to properly translate cuda for its amd counter parts
system2 14 hours ago [-]
I wish there were a way to use RDNA1 cards with CUDA for AMD. My 5700XTs are sitting in a drawer.
monster_truck 13 hours ago [-]
RDNA1 isn't good for a whole lot, even flagship RDNA2 cards are a stretch for many things. The lack of WMMA/matrix multiply/BF16 is too severe of a penalty.
The FP16 throughput on RDNA1 is both shader reliant and requires everything to be packed first. Even with 2 or 4 or 1000 cards, you would be consuming all of the available memory and memory bandwidth just packing and unpacking values, and if you really want to dump a hundred billion tokens into making it work anyways, you're only going to find out that even if you bother to sit there ferrying packed values to ram or disk before then issuing the instructions, paying that already severe penalty again when the values then have to be unpacked is so steep of a cost that the 256 BF16 flops/cu/clock's effective throughput is outright lower than simply doing it on a Zen 2 processor. You also don't have INT8 (or really INT4) on RDNA1 so the other RNS/CRT tricks aren't viable.
Sadly RDNA1's VCN2 also lacks actually good x264 bframe encoding support, or even P010 for 10 bit color, so what I'm saying is you should sell them. Used Radeon VII's are like $260, you'll go a lot further with those especially if you throw in a 7900XTX, and then augment that further with a 9070 CRE (you only want it for its int8 cores), and of course 128GB of ram.
E: And sure, that's 3, or ideally 4 GPUs, and a good bit of extra work. But that gets you up to more than halfway to the naive performance of a $15,000 MI300x in a surprising amount of cases, with additional strengths that it lacks. For far less than half of the cost
system2 13 hours ago [-]
I agree, I should've sold them last year when they hit $500 each. I have like 8 of them from my mining days. What a silly mistake I made.
dracotomes 11 hours ago [-]
I still have a 5700XT I bought in 2019 (i think) for 300€ in my gaming rig. Crazy that they were going for $500 6 years later.
system2 10 hours ago [-]
I just checked, they are going for $150-180 on eBay U.S. I guess I will let them go now.
monster_truck 10 hours ago [-]
It's volatile as all get out and I'm not going to call out any token by name but if you needed another nudge, you can absolutely cover the cost of power and the 9070 GRE (or even XT) itself before the warranty expires by mining (without holding/speculating), which has been my breakeven point for sidestepping any guilt I might feel from buying another flagship GPU.
But to reason in other direction, unless you absolutely need cards right now, you could throw that ~$1440 in a 6 month CD and let the 4.5% pay for the tax or shipping on a 10090 XT or whatever RDNA 5 flagship when those drop in about as much time. If it lands anywhere close to what the rumors are indicating it should be a fucking monster.
Nexxxeh 10 hours ago [-]
You'll be doing gamers a favour, coz the AI boom has be a slaughter for PC gaming. The price of RAM, storage, and graphics...
So far, it has only been tested on my RX 9060 XT (gfx1200), where I’ve used it with CUDA-enabled LibTorch workloads, including long ai training and use.
I also added a GPU scanner / auto-detection system that detects:
AMD GPU model
gfxXXXX architecture
ROCm/HIP installation
driver info
whether the GPU has already been validated by the project
The goal now is to test it on more hardware, especially RX 6000 / 7000 / 9000 cards.
If you have an AMD GPU on Windows and want to try it, I’d really appreciate compatibility reports working or broken. There’s a dedicated GPU compatibility issue template in the repo.
If this is useful to you, a star would also help the project get more testers.
harhargange 5 minutes ago [-]
How about Linux support? I have 7900xt with linux
nine_k 13 hours ago [-]
(As a side note, I love the name ZLUDA; it very aptly means "delusion" or "deception" in Polish.)
swerner 10 hours ago [-]
TIL, I didn’t know that. I always assumed it came from level zero”, the Intel computer layer that ZLUDA was translating to before its developer was hired by AMD to target HIP.
It's unbearable that most LLM inference happens on closed H/W, closed drivers, and closed SDKs.
I would really appreciate your input!
1. Top end model on high/xhigh thinking (last time I did it it was Sol xhigh I think)
2. Make sure it creates some representative fixtures of different sizes and sets up a good testing, profiling and benchmarking loop that doesn't require my input.
3. Make sure it has access to reference implementation code
Edit: Oh and one obvious pitfall that for some reason I still have to remind even smart models of from time to time: make sure it knows not to try to parallelize its benchmark runs. I've occasionally had an agent struggle to figure out absolutely nonsensical data because it tried to run multiple tests on the same compute hardware simultaneously.
My software is labeled "CPU only unless using an nVidia GPU". I would prefer to strikethrough "nVidia". Incidentally, this means no more Mac support.
Few problems I noticed:
* coopmat2 from nvidia is the classic embrace, extend, extinguish. No point to ask the models to translate from CUDA to coopmat2. Instead, the models can understand the existing CUDA and CPU kernels, and adapt them accordingly to non-nvidia devices.
* However, the standard API is also lacking. The models struggled to make prompt processing compute-bound on strix halo when the graph is complex. Upfront standard API might just be an evolution dead end.
Sucks like important libraries like Alphafold are locked into CUDA. Its ridiculous for researchers.
It's likely that CUDA will continue dominating until they put aside their differences. The current MLX/MPS/ROCm ecosystems are too fractured to threaten Nvidia.
Intel uses SPIRV iirc
They're migrating away from SPIR-V to their own, Intel PISA: https://discourse.llvm.org/t/rfc-upstreaming-the-pisa-backen...
Vulkan's SPIR-V dialect is substantially different from the OpenCL one, notably with the former having structured control flow. They're incompatible between each other.
The basic underlying tech can be agreed on, but Apple/AMD/Intel all have different GPU priorities that limit their ability to agree on a CUDA-adjacent hardware platform.
Intel missed for a different reason - they didn't invest in the product space at all for decades. In terms of units they had the most market share (millions of Intel Integrated Graphics chips), but it wasn't seen as important. Bare minimum to render Windows and Office UI, nothing more.
Intel (via Codeplay) was handing it out on a silver platter - Nvidia on SYCL, full top chain, and people still wouldn’t want it.
By holistic, I mean hardware architecture cooperation. Nvidia can hold onto their lead forever if GPU designers fight over what a GPGPU hardware baseline looks like. The current ecosystem fragmentation is not competitive, and future fragmentation probably wouldn't work either. I think the fastest way to kill Nvidia would be a hardware consortium.
What would you expect the hardware consortium to coordinate on? Unified ISA?
Yes they have implementations on top of CUDA but they're maintained by... Intel. They didn't get buy-in for cross-vendor collaboration
Source: worked at a bunch of accelerator companies in the kernels or equivalent team. They're nothing alike.
My thinking was rather that most of our current programming languages put memory layout fully into the programmer’s responsibility - I can think off hand of a language where the compiler makes performance decisions like whether your structure are SoA, AoS or SoAoS, what alignment, padding, strides and float types to use.
Automatic decisions about when to use cooperative loads through shared local mem versus gathers from global mem and hardware caches are also something that such a hypothetical compiler would have to make.
As for ai and matrix vector performance... I mean matrices are extremely useful across many domains. The hands off language that exists today is called blas. That's fine but won't lead to the best perf on any GPU today.
SoA and AoS data layouts are not even a worthwhile point of contention. Same with shared v global mem. Today's hardware has specialized memory depending on the operation. The hardware on these processors is so specialized as to make anything but first class support for the feature be completely pointless. If you look at Nvidia code that's open source even they will special case a lot of their chips. Literally if you want the best perf you write the kernel exactly for the exact chip. That's intra vendor .. you can only imagine inter vendor
ZLUDA is already doing that, no?
Src: https://github.com/vosen/ZLUDA
the source language has never been the moat. Nvidia sells to hyperscalers. Hyperscalers have armies of kernel authors who have no issue translating shaders by hand (or now with claude). Nvidia's moat is (and will remain for the foreseeable future) the entire stack. you cannot fathom the pain and misery of working on literally any other stack. if you've never debugged a GPU synchronization error or kernel panic due to some GPU firmware bug or fought absolute shit profilers hunting for perf you really have no idea what you're talking about.
EDIT: i can't believe this really requires saying but graphics and compute are not the same domain at all. if you work in graphics for GPU but not compute then you are still way out of your depth commenting. to wit: graphics people do not (and cannot) write CUDA kernels/shaders.
You can simply disagree with me, regardless of my experience (or lack thereof).
that's exactly what i did and made an argument for why i think you're wrong. in response you provided exactly zero substantive remarks other than "i've written shaders" and then accused me of pissing.
also FYI it's clear from your profile that you've only worked on graphics (embree, blender, etc) and not compute. so i'll repeat: you're an outsider and you have absolutely no idea what you're talking about.
“if you've never debugged a GPU synchronization error or kernel panic due to some GPU firmware bug or fought absolute shit profilers hunting for perf”
I have done all of those things. As part of my full time job, for years.
Now that we’ve put all of that aside, can we stop talking about me and go back to discussing moats? What do you think are top three things that are holding customers back from buying AMD GPUs instead of Nvidia GPUs?
I could be misremembering, but I think Jensen Huang himself once called CUDA or the CUDA ecosystem their moat, and it certainly seems to be accepted narrative in the tech press. They may be wrong there, and you sharing your first hand experience here would be helpful to many of us readers here.
My 7900XTX is supported, I run local models via rocm all the time recently, mostly to play with/experiment on, Vulcan works as well and for some models works better (or the trade offs are better for that use case).
Their mistake was simply not picking and going all in earlier, they let nvidia become the defacto standard without even contesting it on both the hardware side and software side and that’s a hard though not impossible comeback to make.
Long term I think they’ll catch up in capability if not market share because simply too much money on the table not to.
https://rocm.docs.amd.com/_/downloads/radeon-ryzen/en/docs-6...
“graphics people do not (and cannot) write CUDA kernels/shaders” is just not true at all. All it would take to verify that would be things like reading the introduction of the OptiX documentation, a small sample of SIGGRAPH GPU papers or the Blender/Cycles source code.
AMD GPUs build for AI specs for reference: https://flopper.io/gpus?vendor=AMD&page=1
- what exactly is CUDA?
- is it patented hardware tech that AMD cannot replicate?
- is it a library that ll also work on AMD while it currently works on nvidia
- can AMD cook an equivalent of CUDA, if so why havent they done it?
The FP16 throughput on RDNA1 is both shader reliant and requires everything to be packed first. Even with 2 or 4 or 1000 cards, you would be consuming all of the available memory and memory bandwidth just packing and unpacking values, and if you really want to dump a hundred billion tokens into making it work anyways, you're only going to find out that even if you bother to sit there ferrying packed values to ram or disk before then issuing the instructions, paying that already severe penalty again when the values then have to be unpacked is so steep of a cost that the 256 BF16 flops/cu/clock's effective throughput is outright lower than simply doing it on a Zen 2 processor. You also don't have INT8 (or really INT4) on RDNA1 so the other RNS/CRT tricks aren't viable.
Sadly RDNA1's VCN2 also lacks actually good x264 bframe encoding support, or even P010 for 10 bit color, so what I'm saying is you should sell them. Used Radeon VII's are like $260, you'll go a lot further with those especially if you throw in a 7900XTX, and then augment that further with a 9070 CRE (you only want it for its int8 cores), and of course 128GB of ram.
E: And sure, that's 3, or ideally 4 GPUs, and a good bit of extra work. But that gets you up to more than halfway to the naive performance of a $15,000 MI300x in a surprising amount of cases, with additional strengths that it lacks. For far less than half of the cost
But to reason in other direction, unless you absolutely need cards right now, you could throw that ~$1440 in a 6 month CD and let the 4.5% pay for the tax or shipping on a 10090 XT or whatever RDNA 5 flagship when those drop in about as much time. If it lands anywhere close to what the rumors are indicating it should be a fucking monster.
https://github.com/Zaneham/Booth
https://scale-lang.com/
I’ve been working on a Windows setup that lets CUDA-targeted applications run on AMD GPUs using ZLUDA + ROCm/HIP.
Repo: https://github.com/Speedstu/CUDA-for-AMD-Windows
So far, it has only been tested on my RX 9060 XT (gfx1200), where I’ve used it with CUDA-enabled LibTorch workloads, including long ai training and use.
I also added a GPU scanner / auto-detection system that detects:
AMD GPU model
gfxXXXX architecture
ROCm/HIP installation
driver info
whether the GPU has already been validated by the project
Example:
RX 9060 XT → gfx1200 → RDNA4 → HIP detected → validated
The goal now is to test it on more hardware, especially RX 6000 / 7000 / 9000 cards.
If you have an AMD GPU on Windows and want to try it, I’d really appreciate compatibility reports working or broken. There’s a dedicated GPU compatibility issue template in the repo.
If this is useful to you, a star would also help the project get more testers.