RoCM/HIP
Anonymous 01/22/25(Wed)20:55:49 | 9 comments
An AMD developer is asking what Radeon family should get rocm/hip support the most, I'm an nvidiafag because I've been dissppointed too many times with Radeon, but I'd urge everyone to vote, I'd like to see improvements on Radeon during 2025. They need it.
https://github.com/ROCm/ROCm/discussions/4276
https://github.com/ROCm/ROCm/discus
Anonymous 01/22/25(Wed)21:36:38 No.104002531
>>104002069
steam deck
steam deck
Anonymous 01/22/25(Wed)21:44:36 No.104002623
>>104002069
Embarrassing. The answer is simple and obvious, it needs to support ALL radeon cards. Everything from random old mid-range stuff like the RX580 to the latest flagships. That's what you get with CUDA on NV, and for ROCM to be worth anything at all it needs to be as smooth and compatible as CUDA.
If the design of ROCm doesn't allow for this then it isn't fit for purpose and they need to throw it out and replace it with something that can be supported on all cards.
Embarrassing. The answer is simple and obvious, it needs to support ALL radeon cards. Everything from random old mid-range stuff like the RX580 to the latest flagships. That's what you get with CUDA on NV, and for ROCM to be worth anything at all it needs to be as smooth and compatible as CUDA.
If the design of ROCm doesn't allow for this then it isn't fit for purpose and they need to throw it out and replace it with something that can be supported on all cards.
Anonymous 01/22/25(Wed)22:39:57 No.104003278
>>104002623
aparently amd compiles to isa binary directly, and this is why each card has to be supported individually, since each card has its own isa variant due to features being added as products come out(seems insane to me). this is unlike shader programs which compile to an intermediate representation first , which presumably makes it easier to support myltiple cards. this comes from bridgman a long time amd developer,
aparently amd compiles to isa binary directly, and this is why each card has to be supported individually, since each card has its own isa variant due to features being added as products come out(seems insane to me). this is unlike shader programs which compile to an intermediate representation first , which presumably makes it easier to support myltiple cards. this comes from bridgman a long time amd developer,
Anonymous 01/22/25(Wed)22:44:29 No.104003316
>>104002069
All of them. It makes no sense not to. As an AI developer, even Vulkan has better performance and runs on ALL cards, on ALL operating systems, and works on community drivers.
I refuse to buy NVidia, but it's completely embarrassing that ROCm gets blown out of the water by Vulkan.
All of them. It makes no sense not to. As an AI developer, even Vulkan has better performance and runs on ALL cards, on ALL operating systems, and works on community drivers.
I refuse to buy NVidia, but it's completely embarrassing that ROCm gets blown out of the water by Vulkan.
Anonymous 01/22/25(Wed)23:10:47 No.104003533
It's honestly ridiculous my 6950xt isn't supported in linux.
Anonymous 01/23/25(Thu)01:57:38 No.104004732
AMD should focus on making CPUs and APUs for basic rendering, just drop the discrete graphics market, seriously.
Anonymous 01/23/25(Thu)02:06:15 No.104004784
>>104003278
Well, yes, but then that intermediary has to be compiled to native code at some point so you're back at square one: which ISA should the ROCm compiler support next. The problem is the ROCm team don't have the resources to support a decade's worth of cards. That's the real insane thing, that AMD are still playing the "let's ramp up slowly and try to gain marketshare" when AI slop has put nVidia stock on its way to Mars. AMD should have put everyone on the task and gone full bore. It doesn't matter if ROCm has buggy and ropey support for a while, idiots and shills are going to claim it does regardless because using it while being a dumbass will result in errors that are unrelated and fixed in minutes by upstream that will be used as evidence of how shit it is for years.
Well, yes, but then that intermediary has to be compiled to native code at some point so you're back at square one: which ISA should the ROCm compiler support next. The problem is the ROCm team don't have the resources to support a decade's worth of cards. That's the real insane thing, that AMD are still playing the "let's ramp up slowly and try to gain marketshare" when AI slop has put nVidia stock on its way to Mars. AMD should have put everyone on the task and gone full bore. It doesn't matter if ROCm has buggy and ropey support for a while, idiots and shills are going to claim it does regardless because using it while being a dumbass will result in errors that are unrelated and fixed in minutes by upstream that will be used as evidence of how shit it is for years.
Anonymous 01/23/25(Thu)02:08:15 No.104004794
>>104003278
Wtf rocm sounds like an insane rush job
Wtf rocm sounds like an insane rush job
Anonymous 01/23/25(Thu)02:29:44 No.104004967
>>104004784
I think the problem is that because they don't have an intermediate representation, any features added to the stack have to then be added to each isa individually all the way through or they will suffer breakage, rather than only the final compile being card specific. the (final) compiler then wouldn't have to be updated each time they make a significant change to the rest of the stack presumably, and therefore they could just keep support for older cards without breaking things constantly.
amd already does this for graphics as does nvidia, though I think they do it mainly for supporting multiple apis with 1 compiler.
I think the problem is that because they don't have an intermediate representation, any features added to the stack have to then be added to each isa individually all the way through or they will suffer breakage, rather than only the final compile being card specific. the (final) compiler then wouldn't have to be updated each time they make a significant change to the rest of the stack presumably, and therefore they could just keep support for older cards without breaking things constantly.
amd already does this for graphics as does nvidia, though I think they do it mainly for supporting multiple apis with 1 compiler.