I hope they improve ROCm, and add support for normal GPUs, instead of only 6800xt+.
My 6700xt can't do AI, but a 3050 can, welcome to AMD drivers in the professional world.
They sort of screwed themselves on consumer level hardware support with how they designed ROCm. Unlike CUDA, which compiles to an intermediate representation that can be compiled for the target hardware by the driver (thus allowing everything which meets the minimum feature level to run it), ROCm includes device code for each GPU, which means binary sizes would explode if they supported too many generations and every new generation needs recompiled binaries.
That's also why they struggle to support new consumer hardware, why they led people on about ROCm on 5000 series until 6000 series was around the corner (this move killed my interest in taking ROCm seriously for the near future) and why they dropped support for the rx580 when it was the only consumer GPU that was still available with ROCm.
They're going to have to fundamentally redesign ROCm's build process to come anywhere near CUDA's level of support.
Wow, that's interesting. Do you think this is because they had to design this kind of system much faster than nvidia in order to release something to compete with cuda? Or are there other reasons for this sort of design decision?
Yeah, I think the decision was made that way because they wanted to try to catch up to CUDA but probably didn't really have good tie in with the driver team to put ROCm there. IIRC for a while you used to also have to install a custom driver to use ROCm, although at least that hasn't been necessary for some time.
With ROCm on 5000 series they promised status updates several times which never came and the eventual unofficial support came after 6000 series was out. Then with the Rx580 support, they claimed that while it was unsupported it should still work and several of their developers claimed to be looking into the matter. I recall other similar incidents regarding their other smaller projects under GPUOpen.
So overall it always seemed like they weren't really communicating properly internally, thus all of their projects seem somewhat disconnected from each other, leading to odd decisions like this one.
This is one of the reasons I don’t bet on AMD for GPU outside of gaming. All the other GPU vendors (NVIDIA , Intel, Apple, Qualcomm etc ) are investing strategically on making sure popular software is hardware accelerated by their products. NVIDIA is clearly in the lead here, due to the excellent choices for CUDA, but AMD is the only vendor who seems to not be pushing forward here because their HIP and ROCm strategy seems to be flawed.
On the other hand, I don't think any other vendors aim for compatibility with CUDA. Intel is laser focused on oneAPI which is just SYCL iirc. Sure, SYCL is cool and all, but you cannot trivially translate most CUDA programs to SYCL like you can with HIP.
It’s really insane to me that they target directly to hardware. Especially as a GPU vendor, they’re among the most aware of how much variances there are between different GPU designs.
Pretty much every other GPU targeted language either does a runtime compilation from source or IR.
This has been a known problem+solution for ages and their approach to ROCm is flummoxing.
It’s worse because there is no IR in the driver there is zero guarantee for forward compatibility and you need create binaries for every hardware for backwards compatibility.
So not only does it mean that you have to choose which hardware you want to support at any point in time but you have to maintain your codebase and release new binaries every time AMD releases a new GPU.
And it gets even more complicated because even intra-generation compatibility isn’t granted since differ GPUs from the same generation can have slight variances in them that essentially requires you to target them specifically.
On the other hand CUDA binaries that date back to the days of Tesla and Fermi can still run on current hardware with no issues.
The architecture behind ROCm does not make any sense outside of custom implementations for supercomputers and bespoke hyperscaler size deployments.
The IR per architecture is annoying. Also shipping llvm IR has hazards wrt compatibility with different llvm versions. It's solvable, probably with performance overhead.
None of the consumer Navi 2x cards are 'officially' supported. Nevertheless, you can use the ROCm libraries anyway by setting:
export HSA_OVERRIDE_GFX_VERSION=10.3.0
That will make your gfx1031 card pretend to be gfx1030, which is a supported architecture. Those processors were given different numbers in case an incompatibility was found, but I haven't heard of any thus far.
Obviously, that's not as good as official support, but I hope it helps.
They're not 'officially' supported like you say, but Navi21 cards (6800-6950xt) have undergone the same QA validation as the officially supported pro cards.
Not many people know that Cuda stands for Compute Unified Device Architecture.
The unified being the key idea here. All NVIDIA GPUs support Cuda since the G80/G84/G86 generation which arrived at the end of 2006, beginning of 2007.
It’s true of course that the older GPUs don’t support newer versions of CUDA, but the idea that CUDA is unified has been central to the project since the beginning. It also has cost a lot of money and effort for NVIDIA to put CUDA support in every GPU, even when it wasn’t extensively used. Took about 10 years of investment before it really started to pay off.
Trying to figure out the ROCM hardware support page for a solid 10 minutes and then finding out my RX 5700 which would be pretty capable hardware-wise isn't supported was super frustrating. According to some GitHub Thread GFX10 and 20 should have been supported by the end of 2021 but official support as in being listed in the document never came?
I get that nvidia has a lot more resources and I'm trying not to support their closed ecosystem but AMD's non-support isn't exactly making it easy.
Has anyone here had any experience with intel's new arc line?
The driver and compiler work, but the math libraries were never updated to add gfx1010, aside from rocBLAS and rocSOLVER. The official binaries don't contain machine code for your architecture, aside from those two.
I would suggest building ROCm with Spack if you are using a gfx101x processor. I've been working to make sure that all of ROCm can be built for different targets. e.g.
That will build rocBLAS and run a subset of the test suite. The RX 5700 hardware is not tested by ROCm QA, so running the test suite is usually a good idea.
I have an RX 5700 XT available, which is also gfx1010, so if you encounter any problems and need some guidance, feel free to contact me. My email is in my profile.
I forgot that OpenMP is broken with llvm-amdgpu in Spack at the moment. I hope it will be fixed soon, because OpenMP is used in some of the tests. In the meantime, you may have to remove `--test root` from that install command.
> I hope they improve ROCm, and add support for normal GPUs, instead of only 6800xt+.
Also, AMD should finally support ROCm under Windows. Currently, the only application known by me that uses ROCm under Windows is Blender, and they use a beta version of ROCm from AMD with Windows support for building the respective Blender releases that is not available publicly.
YMMV outside of the blessed list. I did a bunch of testing with a 5700XT a while ago and it worked about as well as a card on the blessed list. If you've already tried it, how does it fail?
Vulkan requires you to ship shaders in spir-v format, it doesn't have a source-level shader language. The generous interpretation is AMD just forgot to ship the source for those spir-v blobs since it would be a different toolchain.
Looking at the size of the blobs, though, I'm not entirely sure why you're claiming "so much" of the functionality is in those blobs. Most of them you could probably pretty trivially disassmeble & understand, especially given all the inputs & outputs are not obfuscated. And the actual function code of many of them look to be relatively small.
kllrnohj already wrote that Vulkan has no predefined source code language for shaders. I can imagine that the SPIR-V code of these shaders could have been hand-optimized by some team at AMD, so a textual reprsentation of this binary code is the version that the engineers at AMD work on.
Also: the license of the repository is MIT license, so you are free to reverse-engineer these shaders and port them to a high-level language of your choice.
What? It has been in mesa for many months (I run a custom elf/linux distro for AMD hardware)? BTW, it is kind of big, complex and it is not cleanly compilable-out, some patches are still needed for that.
This is not the driver. As stated in the first sentence of the link, what is being discussed is "part of their developer software suite for helping to profile ray-tracing performance/issues on Windows and Linux with both Direct3D 12 and the Vulkan API."
