[trws]

They do need to rework their development processes. It’s worth noting though that there are two (kinda three) different drivers with very different quality and different teams behind them.

There’s the binary driver, on windows and the fglrx driver for Linux, that contains the full OpenGL stack and all the proprietary stuff. That’s been maintained and extended since the ATI days by a team primarily based in Markham. It’s garbage. It’s been garbage since the 90s. This is not new or surprising. It’s unstable, poorly maintained and just generally a bad time. It was also the reason OpenCL required an X session run as root with no access control and sometimes a stub dvi cable on the card for many years. It is a source of endless sadness and despair.

The other driver is the HSA/ROCM driver on Linux, which can be used with the amdgpu upstream kernel driver and is itself upstream. The amdgpu driver is 2d only, but has been developed in the open, and stable, for a long, long time. It’s maintained by a completely separate set of teams mostly in (last I knew) Germany and Austin. The HSA driver has likewise been immensely more stable than the binary drivers since it was introduced. There are potential problems with it, but I’ve managed to recover every single one I’ve run into without a reboot, and I’ve been doing GPU compute with AMD, NVIDIA and intel since 2008. When it was the binary driver, we needed reboots every time an AMD GPU locked up. I’m not saying there’s no problem here, but he’s reporting problems I’ve never seen in thousands of hours of high-load compute both personally and for work with the driver one ought to use for ROCM. There are other problems, but HSA/amdgpu drivers have not been high on that list for me. Possibly because I was so used to how bad the other ones were I guess…

[rstat1]

I believe your info is a bit out-of-date.

FGLRX hasn't been maintained or actively developed for a quite a while and unless you're using super-duper-ancient HW no one actually uses it anymore.

AMDGPU is the the current Linux driver, combined with Mesa, and certainly is not 2D only.

[pezezin]

Yup, FGLRX was deprecated from all major distros in 2016. Nobody has used it for ages.

[sspiff]

Aren't the relevant 3D bits in userspace (not the driver)?

Isn't the concept of 3D APIs limited to stuff like Mesa, with the kernel space AMDGPU driver providing only the primitives on which the API can then be built? I could be wrong, but that's how I understood it.

I things like Fglrx, the OpenGL stack was part of the driver proper IIRC.

But granted, I haven't heard of or seen FGLRX in literally more than a decade, and describing AMDGPU as 2D only is misleading or pedantic.

[bayindirh]

AMDGPU enables the whole hardware sans the video encoders. 3D is standard OpenGL, provided by Mesa.

It's fully accelerated, incl. video decoding & HDCP. Full stack sans the card firmware is open source.

The video decoder block is completely independent from HDCP block on the silicon to be able to provide open access to these parts too.

I don't know why they can't/don't open source video encoder parts. Probably some 3rd party royalties, but I'm not sure.

If you want another 3D API, you can directly build it on top of the driver. Nothing prevents that. Plus, ROCm packages are landing to "free/main" part of Debian for quite some time.

[pxc]

> The amdgpu driver is 2d only

Huh? People play 3D games on that driver. Or is the 3D part just Mesa in such cases?

[ahartmetz]

It's mostly Mesa. The kernel - user space division is kinda like it would be in a microkernel OS: the kernel provides hardware access and manages permissions and resource (time, memory, energy) allocation. User space does the rest.

The kernel part is not really that small but you get the idea.