[AnthonyMouse]

This has been the case for a while because AMD never had the resources to do software well. But their market cap is 10x what it was 5 years ago, so now they do. That still takes time, and having resources isn't a guarantee of competent execution, but it's a lot more likely now than it used to be.

On top of that, Intel is making a serious effort to get into this space and they have a better history of making usable libraries. OpenVINO is already pretty good. It's especially good at having implementations in both Python and not-Python, the latter of which is a huge advantage for open source development because it gets you out of Python dependency hell. There's a reason the thing that caught on is llama.cpp and not llama.py.

[dogma1138]

AMDs problem with software goes well beyond people they can’t stick with anything for any significant length of time and the principal design behind ROCm is doomed to fail as it compiles hardware specific binaries and offers no backward or forward compatibility.

CUDA compiles to hardware agnostic intermediary binaries which can run on any hardware as long as the target feature level is compatible and you can target multiple feature levels with a single binary.

CUDA code compiled 10 years ago still runs just fine, ROCm require recompilation every time the framework is updated and every time a new hardware is released.

[AnthonyMouse]

That's all software. There is nothing but resources between here and a release of ROCm that compiles existing code into a stable intermediate representation, if that's something people care about. (It's not clear if it is for anything with published source code; then it matters a lot more if the new version can compile the old code than if the new hardware can run the old binary, since it's not exactly an ordeal to hit the "compile" button once or even ship something that does that automatically.)

[dogma1138]

It’s a must, published source code or not it doesn’t help.

First there is no forward compatibility guarantee for compiling and based on current history it always breaks.

Secondly even if the code is available a design that breaks software on other users machine is stupid and anti user.

Plenty of projects could import libraries and then themselves be upstream dependencies for other projects, many of which may not be supported.

CUDA is king because people can and still do run 15 year old compiles CUDA code on a daily basis and they know that what they produced today is guaranteed to work on all current and future hardware.

With ROCm you have no guarantee that it would work on even the hardware from the same generation and you pretty much have a guarantee that the next update will break your stuff.

This was a problem with all AMD compilers for GPGPU and ROCm should’ve tried to solve it from day 1 but it still adopted a poor design and that has nothing to do with how many people are working on it.

[AnthonyMouse]

> Secondly even if the code is available a design that breaks software on other users machine is stupid and anti user.

Most things work like this. You can't natively run ARM programs on x86 or POWER or vice versa, but in most languages you can recompile the code. If you have libraries then you recompile the libraries. All it takes is distributing the code instead of just a binary. Not distributing the code is stupid and anti-user.

> This was a problem with all AMD compilers for GPGPU and ROCm should’ve tried to solve it from day 1 but it still adopted a poor design and that has nothing to do with how many people are working on it.

It isn't even a design decision. Compilers will commonly emit machine code that checks for hardware features like AVX and branch to different instructions based on whether the machine it's running on supports that. That feature can be added to a compiler at any time.

The compiler is open source, isn't it? You could add it yourself, absent any resource constraints.

[dogma1138]

No most thing’s definitely don’t work like this. I don’t expect my x86 program to stop working after a software update or not to work on new x86 CPUs that’s just ridiculous.

Also if you expect anyone to compile anything you probably haven’t shipped anything in your life.

ROCm is a pile of rubbish until they throw it out and actually have a model that would guarantee forward and backward compatibility it would remain useless for anyone who actually builds software other people use.

[AnthonyMouse]

> I don’t expect my x86 program to stop working after a software update or not to work on new x86 CPUs that’s just ridiculous.

Your x86 program doesn't work on Apple Silicon without something equivalent to a recompile. Old operating systems very commonly can't run on bare metal new hardware because they don't have drivers for it.

Even the IR isn't actually machine code, it's just a binary format of something that gets compiled into actual machine code right before use.

> Also if you expect anyone to compile anything you probably haven’t shipped anything in your life.

Half the software people run uses JIT compilation of some kind.