3 ms·

The GPGPU situation is absolutely ridiculous. Imagine if you couldn't run code for an Intel CPU on an AMD chip, who would buy them? But somehow we accept that o

The GPGPU situation is absolutely ridiculous. Imagine if you couldn't run code for an Intel CPU on an AMD chip, who would buy them? But somehow we accept that our GPUs, small super computers that often cost 50% of the total computer cost, can only run games and vendor proprietary code. I thought we would have this figured out a decade ago. I can't even blame Nvidia, of course they're gonna do what's best for them, and it has worked. I blame AMD for completely dropping the ball on the GPU compute segment, and I blame users for preferring Cuda libraries instead of OpenCL. I hope Intel and maybe AMD can get the GPGPU market to something that resembles something open and most importantly interoperable. But Nvidia has a big head start.

dragonwriter 4y ago
> Imagine if you couldn't run code for an Intel CPU on an AMD chip, who would buy them? Enough people that the Intel standard would lose out and you'd need to ask the reverse question? (See IA64 vs. AMD64.) But if you mean, “what if there was a major microprocessor line incompatible with AMD64”, well, its called ARM and lots of people buy it.
- sorenjan 4y ago
  AMD64 is an extension of x86, it still runs older 32-bit code just fine. I don't see the relevance of IA64, the point wasn't about what Intel have done but about code running on different vendor's platforms. For the most part you can recompile code written for x86 (x64) to run on ARM, and when you do it will run on future ARM processors as well. If you have Cuda code, you can't just recompile it to run on AMD or Intel, and if you compile ROCm code you can't run it on future AMD GPUs or on Windows or Mac. It's objectively a mess compared to the much easier CPU market, even though programmable GPUs have been around for two decades now.
  - Brian_K_White 4y ago
    Right. Pointedly, what happened when AMD came out with AMD64? 1. AMD made it a compatible superset of the existing standard x86. You could still run all other x86 code on it. 2. Intel then immediately made their new chips compatible with it. So if you're writing brand new code, you still don't have to pick only one horse or the other. That was nothing remotely like the gpu situation. Even a totally different ISA like ARM still isn't the same situation. Practically the entire body of c code can be compiled and run on arm or x86 with no more difficulty than optimizing for 486 vs 686. Most of the problems in arm land are just platform integration with bootloaders and peripheral drivers because phones are just not treated like generic user-programmable devices the way pc's started out. Not because it's fundamentally so unique and incompatible with anything else. If the gpu situation were the same, then we would equally have both amd and nvidia drivers that take similar enough interface that a compiler could handle 90% of the translation and there would only need to be a little bit of platform awareness in the code, and as a result, all games and apps would work on all gpus, the same way bash works the same on both my i7 and my pi, and it's such a non-thing that no one even thinks that's remarkable. That's the difference. There is not even a hint of such a problem when it comes to cpu's, even cpus with different ISAs.
fnordpiglet 4y ago
Sort of like how you can’t run ARM on x86 or PowerPC or risc-v?
- Brian_K_White 4y ago
  The fact that you can compile the same c code and run it on all of those is exactly the difference. It doesn't matter that the ISA's are merely different, if the compiler automatically abstracts 99% of the difference. In the end, the developer of a random app doesn't have to do much of anything or care much what cpu the user is on. I have such code myself and it doesn't care. The same is not true for gpus.
  - fnordpiglet 4y ago
    Isn’t this precisely the purpose of OpenCL, OpenACC, etc?
    - Brian_K_White 4y ago
      I think that is the goal, but for various reasons are not actually usable (not good enough, not supported by things you actually need and have no control over, etc) I think part of the problem is unlike the cpu, the isa is not actually available fully. You have to use a blob that does sekrit majik stuff to use the card fully.

dragonwriter 4y ago

> Imagine if you couldn't run code for an Intel CPU on an AMD chip, who would buy them? Enough people that the Intel standard would lose out and you'd need to ask the reverse question? (See IA64 vs. AMD64.) But if you mean, “what if there was a major microprocessor line incompatible with AMD64”, well, its called ARM and lots of people buy it.

sorenjan 4y ago
AMD64 is an extension of x86, it still runs older 32-bit code just fine. I don't see the relevance of IA64, the point wasn't about what Intel have done but about code running on different vendor's platforms. For the most part you can recompile code written for x86 (x64) to run on ARM, and when you do it will run on future ARM processors as well. If you have Cuda code, you can't just recompile it to run on AMD or Intel, and if you compile ROCm code you can't run it on future AMD GPUs or on Windows or Mac. It's objectively a mess compared to the much easier CPU market, even though programmable GPUs have been around for two decades now.
- Brian_K_White 4y ago
  Right. Pointedly, what happened when AMD came out with AMD64? 1. AMD made it a compatible superset of the existing standard x86. You could still run all other x86 code on it. 2. Intel then immediately made their new chips compatible with it. So if you're writing brand new code, you still don't have to pick only one horse or the other. That was nothing remotely like the gpu situation. Even a totally different ISA like ARM still isn't the same situation. Practically the entire body of c code can be compiled and run on arm or x86 with no more difficulty than optimizing for 486 vs 686. Most of the problems in arm land are just platform integration with bootloaders and peripheral drivers because phones are just not treated like generic user-programmable devices the way pc's started out. Not because it's fundamentally so unique and incompatible with anything else. If the gpu situation were the same, then we would equally have both amd and nvidia drivers that take similar enough interface that a compiler could handle 90% of the translation and there would only need to be a little bit of platform awareness in the code, and as a result, all games and apps would work on all gpus, the same way bash works the same on both my i7 and my pi, and it's such a non-thing that no one even thinks that's remarkable. That's the difference. There is not even a hint of such a problem when it comes to cpu's, even cpus with different ISAs.

fnordpiglet 4y ago

Sort of like how you can’t run ARM on x86 or PowerPC or risc-v?

Brian_K_White 4y ago
The fact that you can compile the same c code and run it on all of those is exactly the difference. It doesn't matter that the ISA's are merely different, if the compiler automatically abstracts 99% of the difference. In the end, the developer of a random app doesn't have to do much of anything or care much what cpu the user is on. I have such code myself and it doesn't care. The same is not true for gpus.
- fnordpiglet 4y ago
  Isn’t this precisely the purpose of OpenCL, OpenACC, etc?
  - Brian_K_White 4y ago
    I think that is the goal, but for various reasons are not actually usable (not good enough, not supported by things you actually need and have no control over, etc) I think part of the problem is unlike the cpu, the isa is not actually available fully. You have to use a blob that does sekrit majik stuff to use the card fully.