[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.