AMD Execution Thread [2024]

Lol, now we have competing narratives. Hardware Canucks testing with VBS/Memory Integrity On finds no real difference. Hardware Unboxed tests with VBS/Memory Integrity Off and does find a difference. Hardware Canucks found clean installs of OS versions selected different states for VBS, but is that dependent on BIOS settings? Honestly, this is all kind of lol worthy. Now I want to see someone test with 23H2 with and without the patch, and with VBS on and off. Should be four results to get the picture lol.

Thread:
 
AMD’s AI Plan: The Nvidia Killer or a Wasted Effort?
An AMD call to discuss its $4.9 billion acquisition of ZT Systems provided an inside look into how Lisa Su is building her AI empire. She laid down an AMD AI landscape that is polar opposite to Nvidia’s proprietary approach.

In her view, customers have a choice: choose a dystopian Nvidia world in which the company owns the assets, or select AMD’s world, where you can select your partners, hardware, technologies, and AI tools.
 
Best of luck to them. That model didn’t work so hot for OpenCL. Nvidia can move fast because they can provide a full cohesive solution. Too many cooks arguing over standards and timelines is a recipe for going slow.
Absolutely. AMD is clueless on software development. It's very frustrating
 
Best of luck to them. That model didn’t work so hot for OpenCL. Nvidia can move fast because they can provide a full cohesive solution. Too many cooks arguing over standards and timelines is a recipe for going slow.
I'm not sure how you or anyone else are getting the impression that ROCm is somehow an 'open' standard when it's just as "closed/proprietary" as CUDA is from a hardware standpoint since their software stacks only works for their respective vendors. ROCm is only *open* in a sense that AMD let's you see the codebase itself that's being developed over time and nothing more ...

ROCm *does not* have multiple hardware vendors in a committee where they actively participate to discuss specifications, functionality extensions, or it's potential general future directions about it unlike Khronos' OpenGL group where each major hardware vendor effectively had *veto powers*. No such things exists in ROCm since no other vendor develops or participate in it besides AMD who are the only ones with a vested interest in contributing to it ...
 
I'm not sure how you or anyone else are getting the impression that ROCm is somehow an 'open' standard when it's just as "closed/proprietary" as CUDA is from a hardware standpoint since their software stacks only works for their respective vendors. ROCm is only *open* in a sense that AMD let's you see the codebase itself that's being developed over time and nothing more ...

ROCm *does not* have multiple hardware vendors in a committee where they actively participate to discuss specifications, functionality extensions, or it's potential general future directions about it unlike Khronos' OpenGL group where each major hardware vendor effectively had *veto powers*. No such things exists in ROCm since no other vendor develops or participate in it besides AMD who are the only ones with a vested interest in contributing to it ...

I wasn’t referring to ROCm. ROCm is the equivalent of downloading the CUDA language. Tiny piece of the puzzle.

The entire ecosystem includes software written in that language and all of the hardware including chips and networking designed to run it. Good luck crowdsourcing that in a competitive timeframe.
 
I wasn’t referring to ROCm. ROCm is the equivalent of downloading the CUDA language. Tiny piece of the puzzle.

The entire ecosystem includes software written in that language and all of the hardware including chips and networking designed to run it. Good luck crowdsourcing that in a competitive timeframe.
Then why did you make a mention of OpenCL ?
 
It’s an example of crowdsourced tech.
Explain how you would classify ROCm as "crowdsourced" in the same vein as OpenCL when the former has only *ever* had a total of one relevant contributor (AMD) in the entire project history of it's development while OpenCL had an entire committee (multiple Khronos members) at the very start of it's life ?
 
Explain how you would classify ROCm as "crowdsourced" in the same vein as OpenCL when the former has only *ever* had a total of one relevant contributor (AMD) in the entire project history of it's development while OpenCL had an entire committee (multiple Khronos members) at the very start of it's life ?

I never mentioned ROCm. You did.
 
Then why did you make a mention of OpenCL ?
It’s an example of crowdsourced tech.

I don't think it's correct. OpenCL specs are open, but most driver implementations are proprietary closed source; and ROCm is an exact opposite of that.


OpenCL 1.x C-language spec was originally developed by Apple then submitted to the Khronos Group, so it was not 'crowdsourced'.
C++ language in OpenCL 2.x and 3.x was indeed developed by the Khronos consortium, but it didn't take off, and most OEMs stuck with OpenCL 1.x and C (NVidia obviously wanted to promote their own C++ dialect from CUDA; and other vendors probably didn't have the resources to rework their proprietary OpenCL C compilers to full-blown C++.)

That's why AMD decided to start ROCm (Radeon Open Compute), which is essentially an open-source implementation of AMD Common Language Runtime that hosts both the OpenCL 2.x C-language dialect and the HIP C++ dialect, which is a subset of CUDA API and related C++ language extensions; there were also additional C++ based languages/compilers/runtimes like HCC and C++ AMP, which have since been dropped.

ROCm does use open-source implementations of graphics driver and runtime (in Linux) and a fork of the open-source Clang compiler (maintained as a branch within the main repository), and most roc* / hip* libraries are ports of established open-source frameworks into HIP C++, which mirror Cu* versions shipped with CUDA.


So most (but not all) of critical code is indeed open-source - however in reality ROCm is primarily maintained by full-time AMD employees and is hosted in private repositories, so it's still far from being 'crowdsourced' (though AMD plan to open-source more parts). But at least it does make finding and fixing trivial compiler / library bugs a lot easier comparing to purely proprietary code.

Also ROCm isn't really a 'specification', just a set of APIs and C++ language extensions and libraries that roughly mirror those supported by CUDA (although it's still not a 100% equivalent), so it's not 'crowdsourced' either (and its maintainers routinely make breaking changes through each minor release).

[Edit] ROCm is also 'open' and not proprietary because the HIP runtime can run on CUDA hardware - so if you convert your code to HIP, you can still run it on both AMD and NVidia hardware.


So I don't really see many parallels with OpenCL and its C-language dialect, except that ROCm runtime and drivers were forked from OpenCL runtime and driver (in Linux) and implemented on top of a common foundation.


trini only attributed the crowdsourcing problem to OpenCL, ROCm wasn't even mentioned in any context.

But the HPCWire article above never mentions OpenCL either, it only talks about ROCm - however, much of that talk seems like a misunderstanding on their part, because AMD's "Unified AI Software Stack" effort started in 2022 has never been about unifying all of their proprietary APIs under the ROCm umbrella.

The plan was to continue supporting major AI frameworks through existing APIs/runtimes/compilers developed by Radeon and Xilinx teams, like ROCm / HIP and Vitis / AIE, but merge common parts of the stack into a unified middle layer based on the ONNX runtime and MILR intermediate representation (which was specifically designed for graph-based workflows typical in ML frameworks).

This would enable real-time cross-compilation for specific accelerator hardware that's present on the end system (and may even potentially allow the stack to run on non-AMD hardware with a SPIR-V / Vulkan target).

 
Last edited:
BTW here are the slides from a presentation by Victor Peng, the head of the Xilinx division, published on the AMD Financial Analyst Day 2022 (animated GIF):

AMDUnifiedAIStack.gif
https://ir.amd.com/news-events/financial-analyst-day
Victor Peng. Adaptive and Embedded Computing Leadership (FAD 2022_Victor_Peng_Final Post.pdf)


Compare with a recent version of the slide published on the AMD Zen 5 Tech Day in July 2024, which only concerns Ryzen APUs and thus completely omits ROCm and dedicated GPUs:

AMD_unified_AI_lrg.png
https://www.phoronix.com/news/AMD-Unified-AI-Software-Stack
https://www.phoronix.com/news/Unified-AI-Software-MLIR-SPIR-V


This is largely the same as the diagram currently posted on the 'Ryzen AI Software' page, though the latter provides additional fine details such as ONNX conversion and quantisation layer and ONNX Execution Providers for supported CPU, GPU, and NPU hardware.


NB. Victor Peng has retired from AMD effective August 30...
 
Last edited:
Did you read the linked article that I responded to?
Indeed I did but I should return that very inquiry to you because how exactly does mentioning OpenCL or 'crowdsourcing' represent a non-competitive relationship between AMD and Broadcom who wants to provide switches ?
 
Indeed I did but I should return that very inquiry to you because how exactly does mentioning OpenCL or 'crowdsourcing' represent a non-competitive relationship between AMD and Broadcom who wants to provide switches ?

It’s literally the first two paragraphs. Can you stop pretending you don’t understand what I’m referring to?

She laid down an AMD AI landscape that is polar opposite to Nvidia’s proprietary approach.

In her view, customers have a choice: choose a dystopian Nvidia world in which the company owns the assets, or select AMD’s world, where you can select your partners, hardware, technologies, and AI tools.
 
Back
Top