Re: ROCm in-box support at Computex 2025
Hi Cory,
On 2025-05-22 06:50, Cordell Bloor wrote:
> At Computex 2025, AMD announced its intentions to 'in-box' the ROCm
> stack by integrating it into a number of Linux distributions
Hoping that this eventually happen was my main motivation to contribute
to the Team, back when GPUGPU compute took off 2023 thanks to ChatGPT.
As I mentioned a long time ago, being able to just `apt-get install
rocm` like one installs gcc, without having to deal with license
considerations as with CUDA, would be one killer feature over CUDA.
> including Fedora, EPEL, SUSE, and Ubuntu [1]. While Debian is not on
> this list, I expect that the work done for Ubuntu will be quite
> beneficial for the Debian effort. The packaging work for ROCm in-box
> on Ubuntu builds upon the packaging work done for ROCm in-box
This is a big win for open source. But egotistically as this might
sound, I found this part saddening, because in the end, Debian got left out.
First: "Ubuntu builds upon [..]" is an understatement. TTBOMK, whatever
ROCm support Ubuntu has now, was produced almost entirely by the
initiative and the substantial work of many Debian contributors [1] over
a period of three years, and with significant funding by the Project for
our CI; work which then landed downstream.
This is absolutely not meant as an attack on Ubuntu! I consider this
rivalry that some see between Debian and Ubuntu to be utterly childish.
I couldn't care less where contributions come from; I myself have
enjoyed many great collaborations with Ubuntu developers, and I am of
course aware that many good parts of Debian would not be what they are
without Ubuntu people doing the work (and Canonical funding them).
But purely factually speaking, it just happens to be that in this
particular case, everything ROCm in the Debian/Ubuntu world is, TTBOMK,
100% the result of Debian-driven effort.
I of course understand the business decision of first officially
supporting Ubuntu. But in light of the above, I consider not also
supporting Debian puzzingly short-sighted. Not just not because of the
missed two-birds-one-stone opportunity, but because it fails to
recognize the work Debian has done so far, and leveraging that for
future results.
And we now all find ourselves in the strange situation where new
packaging contributors will need to be onboarded from the Ubuntu side,
whereas contributors from Debian must re-evaluate how to continue (see
below).
> on Debian, and will feed back into Debian as well.
Following from this and the fact that ROCm will be "solved" in Ubuntu,
I wonder whether there is any point in doing active development work for
ROCm in Debian anymore, instead of just waiting for the work in Ubuntu
to be done, and then to upstream it. And I say this without any
bitterness, just with brute reason:
(1) We know the packaging will happen for Ubuntu, so there is little
point in expending our own limited capacities, rather than to wait
for that. That doesn't just avoid duplication, it reduces the risk
of conflicting development paths.
(2) We can expect that ROCm in Ubuntu will see extensive CI testing,
so again, there is little point in operating, much less expanding,
our own CI.
Again, I realize how egotistical this might sound, and I'm sorry for
that. I know this is a win for open source in general, I just wish this
were more of a win for Debian, given how much we contributed to this.
Best,
Christian
[1] Not to diminish the extra Ubuntu work you did get our packages
updated and synced for 24.04.
Reply to: