Yeah, that kinda sucks, but, all their new generation onboard GPUs are supported by ROCm. e.g. Ryzen AI 395 and 400 series which will be found in mid-to-high end laptops and desktops and motherboards. They seem to have realized that the reason Nvidia is kicking their ass is that people can develop with CUDA on all sorts of hardware, including their personal laptop or desktop.
ROCm is finally getting better due to a few well meaning engineers.
But let’s be honest, AMD has been an extremely bad citizen to non-corporate users.
For my iGPU I have to fake GFX900 and build things from source or staging packages to get that working. Support for GFX90c is finally in the pipeline…
The improvements feel like a bodyguard finally letting you through the door just because NVIDIA is eating their lunch and they don’t want their club to be empty.
They strongarm their customers to using “Enterprise” GPUs to be able to play with ROCm, and are only broadening their offerings for market share purposes.
Yup, meanwhile Jensen is on the Lexfriedman podcast stating the reason why CUDA is successful is because all thier devices run it. The on ramp is at the individual user.
I have and RDNA4 card and they certainly are prioritizing CDNA over a CDNA + RDNA strategy or a unification strategy.
Debian build their ROCm with support for all possible devices. If you are tired of compiling from source just use a Debian Stable container, install their libraries in your container build, and pass /dev/kfd and /dev/dri to the container. No ROCm or out-of-tree drivers required on the container host, just regular upstream Linux kernel amdgpu and those two devices to the container.
It's also probably worth trying Vulkan inference. It is now faster than ROCm - both tg and pp over 16k ctx - on Strix Halo so maybe you'll see the benefits too.
Great that you used AI to build something useful, but it’s still weird to me when someone says “I built this”. Maybe the more correct way to say this is “I spec’d this”
Generally kernel level attacks and neighbor performance impacts on the security side.
On the functional side without a kernel per guest you can't allow kernel access for stuff like eBPF, networking, nested virtualization and lots of important features.
theoretically you can get to fairly complete security via containers + a gVisor setup but at the expense of a ton of syscall performance and disabling lots of features (which is a 100% valid approach for many usecases).
I think eBPF is a valid example, because it allows you to program the kernel to some extent. That being said and assuming it's not important to your individual goal, why is a rootless podman container running rootless podman inside the container still not sufficient? Do you really need nested virtualization? What are some of those other important features?
I met a traveller from an antique land,
Who said: “Two vast and trunkless legs of stone
Stand in the desert. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed;
And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.
I take that more as a rumination on the futility of vanity and self-aggrandizing rather than "ruling the world " which in the modern day comes down to politics. Yes, there is considerable overlap with ego, but there's more to that topic than pure self-worship.
reply