4 ms·

There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not b

There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not be so bound.

dogma1138 3y ago
The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. ROCm will be pointless until at least forward compatibility will be guaranteed by design.
- nimish 3y ago
  CUDA is subsequently compiled to the hardware assembly at runtime isn't it? Like precompiled shaders. C++ -> PTX -> Hardware ISA
- StillBored 3y ago
  How so? One of the ROCm layers is opencl which does runtime target compilation, and there is also the various intermediate language representations. So, presumably much of this is just lack of sufficient resources to assure that all the different combinations are optimally being compiled down on all the independent HW devices. This was always the OpenCL problem too back before everyone just started using CUDA rather than trying to use it. It worked in a lot of places but the higher level code needed to be adjusted for individual devices because each vendor would do a reasonable job maintaining optimal code generation for their target given code optimized for their target, but switching vendors (AMD<->nvidia) would result in needing two different versions of the code tuned for the individual vendors ideas of how code should be tuned for their platform. If that wasn't clear say you wrote and optimized code for vendor A's device X, when vendor A released device Y, things tended to work well, but moving that code to vendor B's devices basically required retuning/rewritting things.
- mathisfun123 3y ago
  Someone else already said it but it beats repeating: this is wrong > The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. PTX isn't an ISA and it goes through another translation step before it hits the real ISA (SASS), which does change internally. Though you are right that PTX as intermediate is part of the reason for CUDA's success in that it makes the code portable across cards.
somat 3y ago
There is a huge business reason to restrict the isa. simple stable interfaces are very attractive to users(buyers). Take amd64 as a counter example, not only does it not take 4 million lines of code to interface with an amd64 processor, when something new is added the processor is still compatible with existing code. x86 as an architecture is a bit of a train wreak but much of it's success is the effort to keep the interface stable. Also for example arm, this is getting better but the hardest part about using arm is the isa is all over the place, every single bloody SBC appears to have a different isa.
- sroussey 3y ago
  The only users of the isa are the drivers. No one currently or in the decades past has done otherwise.

There is no business reason to restrict themselves on the ISA, and it would be make their hardware less performant compared to the competition which would not be so bound.

dogma1138 3y ago

The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. ROCm will be pointless until at least forward compatibility will be guaranteed by design.

nimish 3y ago
CUDA is subsequently compiled to the hardware assembly at runtime isn't it? Like precompiled shaders. C++ -> PTX -> Hardware ISA
StillBored 3y ago
How so? One of the ROCm layers is opencl which does runtime target compilation, and there is also the various intermediate language representations. So, presumably much of this is just lack of sufficient resources to assure that all the different combinations are optimally being compiled down on all the independent HW devices. This was always the OpenCL problem too back before everyone just started using CUDA rather than trying to use it. It worked in a lot of places but the higher level code needed to be adjusted for individual devices because each vendor would do a reasonable job maintaining optimal code generation for their target given code optimized for their target, but switching vendors (AMD<->nvidia) would result in needing two different versions of the code tuned for the individual vendors ideas of how code should be tuned for their platform. If that wasn't clear say you wrote and optimized code for vendor A's device X, when vendor A released device Y, things tended to work well, but moving that code to vendor B's devices basically required retuning/rewritting things.
mathisfun123 3y ago
Someone else already said it but it beats repeating: this is wrong > The competition is very much bound to a rather narrow ISA which is why CUDA is forward and backwards compatible whilst ROCm isn’t. PTX isn't an ISA and it goes through another translation step before it hits the real ISA (SASS), which does change internally. Though you are right that PTX as intermediate is part of the reason for CUDA's success in that it makes the code portable across cards.

somat 3y ago

There is a huge business reason to restrict the isa. simple stable interfaces are very attractive to users(buyers). Take amd64 as a counter example, not only does it not take 4 million lines of code to interface with an amd64 processor, when something new is added the processor is still compatible with existing code. x86 as an architecture is a bit of a train wreak but much of it's success is the effort to keep the interface stable. Also for example arm, this is getting better but the hardest part about using arm is the isa is all over the place, every single bloody SBC appears to have a different isa.

sroussey 3y ago
The only users of the isa are the drivers. No one currently or in the decades past has done otherwise.