3 ms·

You would think so, and yet AMD dropped the ball so hard on the software side of things, the resulting hole in the ground might as well be bottomless.

jorvi 3y ago
Is that really just on AMD? All the companies that are now screaming hellfire because of Nvidia's market maker position are also the companies that gave Nvidia a warchest filled with billions of dollars. How is AMD supposed to compete when the whole market is funding their rival?
- HideousKojima 3y ago
  The whole market funded Nvidia because AMD failed to provide a viable alternative for 10+ years
  - deleted 3y ago
    [deleted]
  - doikor 3y ago
    AMD was almost bankrupt 10 years ago. Basically AMD had to bet the whole company on their next CPU or GPU and their choice was the CPUs and put all their efforts into that and it payed off (Zen architecture). It has only been the last 4 or 5 years that AMD has had any real money to put into their GPU/AI accelerator sector and that seems to be developing quite well now (though they seem to be mostly interested in super computer/massive data center deployments for now)
  - fulafel 3y ago
    GPU languages shouldn't be proprietary. At one point this was a shared understanding and lots of companies were behind initiatives like OpenCL. Meanwhile progress in higher level non C++ GPU languages has stayed in niches without big industry backing, and we're stuck with CUDA which is bad in both language design sense and market-wise.
    - paulmd 3y ago
      the problem with opencl was that AMD's runtime was so buggy and incomplete that developers usually had to build a whole separate pathway just for AMD. And if you're doing that, you're not portable anyway, so why bother forcing NVIDIA through a more-mismatched generalized API just for the sake of purported "portability"? it's turtles (broken AMD technical leadership) all the way down. this is simply not a field AMD cared about, whether you think they were right or wrong (based on their financials or otherwise). and now that it has turned into a cash fountain, everyone wishes it had gone differently. "should have bought bitcoin" but instead of pollution funbux it's investing into your own product.
      - fulafel 3y ago
        This is a AMD centric view but the problem is much wider, it includes other OS platforms (eg Android & Apple platforms) and other hardware vendors (eg intel, mobile chipsets) as well. After all game APIs were also victim to the same kind of "code to the driver" circumstance. I agree that correctness and robustness of the vendor impolementations went poorly, but it's fixable if there was commitment between vendors, the infighting leading to Apples departure must not have helped that side either. In the end I think including the high level compilers and APIs in the proprietary driver stack responsibility is unsustainable. Microsoft seems to have a better model, or there could be even a standard JIT code consumed by drivers that emitted by open source stacks shared across platforms. The latter way would also better support development of nicer GPU languages.
        paulmd 3y ago
        > In the end I think including the high level compilers and APIs in the proprietary driver stack responsibility is unsustainable. Microsoft seems to have a better model, or there could be even a standard JIT code consumed by drivers that emitted by open source stacks shared across platforms. The latter way would also better support development of nicer GPU languages. OK, let's talk MS. What NVIDIA has done with PTX is basically the same thing as MSIL/CIL. There is a meta-ISA/meta-language that has been commonly agreed, and if you invoke no tokens that the receiving driver doesn't understand, the legacy compiler understands and emits executable (perhaps not optimal) code. The legacy hardware stays on a specific driver and a specific CUDA support level. The CUDA support level is everything, that is your entire "feature profile". It's not GFX1030/GFX1031, it's RDNA3.0/3.1/whatever. NVIDIA has been able to maintain their feature support (not implementation details) in a monotonically increasing sequence. Additionally, they also maintain a guarantee that spec 3.1 guarantees that you can also compile and execute 3.0 code. "Upwards family correctness" I guess. Again, doesn't have to be optimal but the contract is there's no tokens that you don't understand. A Tegra 7.0 compiler can compile desktop 7.0 CUDA (byte/)code etc. https://en.wikipedia.org/wiki/CUDA#Version_features_and_specifications https://en.wikipedia.org/wiki/CUDA#Version_features_and_spec... Legacy driver support doesn't change, so, you can always read PTX, you can always read anything that's compiled for your CUDA Capability Level even if it's from a future toolkit that wasn't released at the time. PTX is always the ultimate "emit code from 2020 and run on the 2007 gpu that only understands CUDA 1.3" relief valve though. If you don't write code that does stuff that's illegal in 1.3... it'll compile and emit PTX, and the Tesla driver will parse and run it. Anyway, let's talk MS. MS could come up with MSIL/CIL. NVIDIA can come up with PTX. Why can't AMD do this? What is unique about GCN/RDNA as a language that you can't come up with an intermediate language representation?
- 7speter 3y ago
  Have a solution (Rocm) that works on all of their modern cards (Rdna 1, 2 and 3 and CDNA)?
  - paulmd 3y ago
    even better, APUs. how about those vega APUs in everyone's AMD laptops and desktops? oh, right, those are EOL'd, security updates only/separate driver package with a quarterly release cycle, even though they're still on store shelves...
    - paulmd 3y ago
      just to emphasize: it is crazy to me that at this moment of frenzy over AI/ML, that AMD is not making better use of their iGPUs. The Vega iGPU is really powerful compared to its contemporaries, it's not WMMA or DP4a capable (iirc) but it still can brute force a lot more than you'd think, it certainly is capable of doing at least a little bit of inference. Remember that the "AI core" in the new meteor lake and hawk point stuff is not really all that gangbusters either... it's a low-power sidekick, for the same types of stuff that smartphones have been doing with their AI cores for ages. Enhancing the cameraphone (these cameras would be complete shit without computational/AI enhancement). Recognizing gestures, recognizing keywords for voice assistant activation. AMD's pitch for the AI core is enhancing game AI. Windows 11/12 assistant. That type of stuff. Vega can absolutely just brute-force its way through that stuff, and it gets more people onto the platform and developing for AMD. It is crazy that if nothing else they aren't at least making sure the APUs can run shit. And again, it's pretty damn unethical imo to be pulling support from products that are still actively marketed and sold. That's a cheezy move. AMD dropped support for Terascale before NVIDIA dropped support for fermi, and NVIDIA went back and added Vulkan support to all their older stuff during the pandemic too. Then they dropped the 28nm GCN families, while NVIDIA is still supporting maxwell. And then they dropped Polaris and Vega, and NVIDIA is still supporting Maxwell (albeit I expect them to drop it very soon imo). The open driver is great under linux because it bypasses AMD's craptacular support. But AMD doesn't support consumer GPUs in ROCm under Linux, and de-facto they don't seem to support ROCm on the open driver in the first place anyway, you have to use AMDGPU-PRO (according to geohot's investigations). This is such a crazy miss. Yes, it's not a powerhouse, but in the era of Win12 moving to AI everything, and games moving to AI-driven computer opponents, etc - Vega can do that ok, and it at least would give people something to open the door and get them developing. If there's a contender for breakout against CUDA, sadly it really seems to be Apple. They've got APUs with PS5-level bandwidth and unified memory, and that's just M1 Max, and they have Metal, and it's supported everywhere across their ecosystem. It lets people dip their toes into AI/ML if nothing else, and lets people dip their toes into metal development. That's the kind of environment that NVIDIA spent a decade fostering, and it's also not a coincidence that the second stop for all these data scientists playing with models is not ROCm but their apple laptops. llama.cpp and so on. Everyone likes the hardware they have in their gaming PC or in their laptop, and it's an absolute miss for AMD to not make themselves available in that fashion when they already have the market penetration. Crazy. https://twitter.com/Locuza_/status/1450271726827413508/photo/1 https://twitter.com/Locuza_/status/1450271726827413508/photo...

jorvi 3y ago

Is that really just on AMD? All the companies that are now screaming hellfire because of Nvidia's market maker position are also the companies that gave Nvidia a warchest filled with billions of dollars. How is AMD supposed to compete when the whole market is funding their rival?

HideousKojima 3y ago
The whole market funded Nvidia because AMD failed to provide a viable alternative for 10+ years
- deleted 3y ago
  [deleted]
- doikor 3y ago
  AMD was almost bankrupt 10 years ago. Basically AMD had to bet the whole company on their next CPU or GPU and their choice was the CPUs and put all their efforts into that and it payed off (Zen architecture). It has only been the last 4 or 5 years that AMD has had any real money to put into their GPU/AI accelerator sector and that seems to be developing quite well now (though they seem to be mostly interested in super computer/massive data center deployments for now)
- fulafel 3y ago
  GPU languages shouldn't be proprietary. At one point this was a shared understanding and lots of companies were behind initiatives like OpenCL. Meanwhile progress in higher level non C++ GPU languages has stayed in niches without big industry backing, and we're stuck with CUDA which is bad in both language design sense and market-wise.
  - paulmd 3y ago
    the problem with opencl was that AMD's runtime was so buggy and incomplete that developers usually had to build a whole separate pathway just for AMD. And if you're doing that, you're not portable anyway, so why bother forcing NVIDIA through a more-mismatched generalized API just for the sake of purported "portability"? it's turtles (broken AMD technical leadership) all the way down. this is simply not a field AMD cared about, whether you think they were right or wrong (based on their financials or otherwise). and now that it has turned into a cash fountain, everyone wishes it had gone differently. "should have bought bitcoin" but instead of pollution funbux it's investing into your own product.
    - fulafel 3y ago
      This is a AMD centric view but the problem is much wider, it includes other OS platforms (eg Android & Apple platforms) and other hardware vendors (eg intel, mobile chipsets) as well. After all game APIs were also victim to the same kind of "code to the driver" circumstance. I agree that correctness and robustness of the vendor impolementations went poorly, but it's fixable if there was commitment between vendors, the infighting leading to Apples departure must not have helped that side either. In the end I think including the high level compilers and APIs in the proprietary driver stack responsibility is unsustainable. Microsoft seems to have a better model, or there could be even a standard JIT code consumed by drivers that emitted by open source stacks shared across platforms. The latter way would also better support development of nicer GPU languages.
      - paulmd 3y ago
        > In the end I think including the high level compilers and APIs in the proprietary driver stack responsibility is unsustainable. Microsoft seems to have a better model, or there could be even a standard JIT code consumed by drivers that emitted by open source stacks shared across platforms. The latter way would also better support development of nicer GPU languages. OK, let's talk MS. What NVIDIA has done with PTX is basically the same thing as MSIL/CIL. There is a meta-ISA/meta-language that has been commonly agreed, and if you invoke no tokens that the receiving driver doesn't understand, the legacy compiler understands and emits executable (perhaps not optimal) code. The legacy hardware stays on a specific driver and a specific CUDA support level. The CUDA support level is everything, that is your entire "feature profile". It's not GFX1030/GFX1031, it's RDNA3.0/3.1/whatever. NVIDIA has been able to maintain their feature support (not implementation details) in a monotonically increasing sequence. Additionally, they also maintain a guarantee that spec 3.1 guarantees that you can also compile and execute 3.0 code. "Upwards family correctness" I guess. Again, doesn't have to be optimal but the contract is there's no tokens that you don't understand. A Tegra 7.0 compiler can compile desktop 7.0 CUDA (byte/)code etc. https://en.wikipedia.org/wiki/CUDA#Version_features_and_specifications https://en.wikipedia.org/wiki/CUDA#Version_features_and_spec... Legacy driver support doesn't change, so, you can always read PTX, you can always read anything that's compiled for your CUDA Capability Level even if it's from a future toolkit that wasn't released at the time. PTX is always the ultimate "emit code from 2020 and run on the 2007 gpu that only understands CUDA 1.3" relief valve though. If you don't write code that does stuff that's illegal in 1.3... it'll compile and emit PTX, and the Tesla driver will parse and run it. Anyway, let's talk MS. MS could come up with MSIL/CIL. NVIDIA can come up with PTX. Why can't AMD do this? What is unique about GCN/RDNA as a language that you can't come up with an intermediate language representation?
7speter 3y ago
Have a solution (Rocm) that works on all of their modern cards (Rdna 1, 2 and 3 and CDNA)?
- paulmd 3y ago
  even better, APUs. how about those vega APUs in everyone's AMD laptops and desktops? oh, right, those are EOL'd, security updates only/separate driver package with a quarterly release cycle, even though they're still on store shelves...
  - paulmd 3y ago
    just to emphasize: it is crazy to me that at this moment of frenzy over AI/ML, that AMD is not making better use of their iGPUs. The Vega iGPU is really powerful compared to its contemporaries, it's not WMMA or DP4a capable (iirc) but it still can brute force a lot more than you'd think, it certainly is capable of doing at least a little bit of inference. Remember that the "AI core" in the new meteor lake and hawk point stuff is not really all that gangbusters either... it's a low-power sidekick, for the same types of stuff that smartphones have been doing with their AI cores for ages. Enhancing the cameraphone (these cameras would be complete shit without computational/AI enhancement). Recognizing gestures, recognizing keywords for voice assistant activation. AMD's pitch for the AI core is enhancing game AI. Windows 11/12 assistant. That type of stuff. Vega can absolutely just brute-force its way through that stuff, and it gets more people onto the platform and developing for AMD. It is crazy that if nothing else they aren't at least making sure the APUs can run shit. And again, it's pretty damn unethical imo to be pulling support from products that are still actively marketed and sold. That's a cheezy move. AMD dropped support for Terascale before NVIDIA dropped support for fermi, and NVIDIA went back and added Vulkan support to all their older stuff during the pandemic too. Then they dropped the 28nm GCN families, while NVIDIA is still supporting maxwell. And then they dropped Polaris and Vega, and NVIDIA is still supporting Maxwell (albeit I expect them to drop it very soon imo). The open driver is great under linux because it bypasses AMD's craptacular support. But AMD doesn't support consumer GPUs in ROCm under Linux, and de-facto they don't seem to support ROCm on the open driver in the first place anyway, you have to use AMDGPU-PRO (according to geohot's investigations). This is such a crazy miss. Yes, it's not a powerhouse, but in the era of Win12 moving to AI everything, and games moving to AI-driven computer opponents, etc - Vega can do that ok, and it at least would give people something to open the door and get them developing. If there's a contender for breakout against CUDA, sadly it really seems to be Apple. They've got APUs with PS5-level bandwidth and unified memory, and that's just M1 Max, and they have Metal, and it's supported everywhere across their ecosystem. It lets people dip their toes into AI/ML if nothing else, and lets people dip their toes into metal development. That's the kind of environment that NVIDIA spent a decade fostering, and it's also not a coincidence that the second stop for all these data scientists playing with models is not ROCm but their apple laptops. llama.cpp and so on. Everyone likes the hardware they have in their gaming PC or in their laptop, and it's an absolute miss for AMD to not make themselves available in that fashion when they already have the market penetration. Crazy. https://twitter.com/Locuza_/status/1450271726827413508/photo/1 https://twitter.com/Locuza_/status/1450271726827413508/photo...