Netgpu and the hazards of proprietary kernel modules

Posted Aug 1, 2020 21:25 UTC (Sat) by flussence (guest, #85566)
In reply to: Netgpu and the hazards of proprietary kernel modules by blackwood
Parent article: Netgpu and the hazards of proprietary kernel modules

Radeons used to be entirely firmware-free and in the spirit of the GPL's “preferred form for modification” until AMD (and someone with root access to the fdo git server) infamously sabotaged the radeonhd effort. Someone then went and retroactively added firmware blob dependencies as far back as R200, which was a fully functional driver without it.

And upstream was rightly pissed off when the DC pull request farce happened, but I think they should've pushed back more instead of capitulating. The kernel's now basically carrying around multiple megabytes of disassembly dumps. Maybe nVidia should try it next.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 2, 2020 11:03 UTC (Sun) by airlied (subscriber, #9104) [Link]

Wow, did you try to be wrong in as many ways as possible in one comment or did it just come naturally?

Netgpu and the hazards of proprietary kernel modules

Posted Aug 2, 2020 23:05 UTC (Sun) by quotemstr (subscriber, #45331) [Link] (1 responses)

> until AMD (and someone with root access to the fdo git server) infamously sabotaged the radeonhd effort.

Wait, what?

Netgpu and the hazards of proprietary kernel modules

Posted Aug 7, 2020 10:42 UTC (Fri) by flussence (guest, #85566) [Link]

What, you aren't aware of the rabbit hole that leads to this masterpiece? Maybe you're better off not knowing.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 3, 2020 17:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

To others who are interested in deciphering these half-truths and lies:

Early Radeon 200 series had completely open drivers, that didn't require any firmware, they included OpenGL support and other nice things. Unfortunately, the later R300/R500/R600 cards had only closed-source drivers (and shitty ones at that).

At this time there were already a pretty decent reverse-engineering NVidia driver. So a reverse-engineering project was started ("avivo") for Radeon 500 series as well. Fortunately, ATI was acquired by AMD and they released a lot of documentation after some back-and-forths about NDAs and legal reviews.

With the availability of the documentation two projects were started: RadeonHD and new code in the existing xf86-video-ati driver (mostly added by airlied and Alex Deucher). The difference was that RadeonHD used direct register manipulation and xf86-video-ati used AtomBIOS.

AtomBIOS is basically an interpreted firmware that is used to manipulate power states, engine intialization and other utility stuff. Supporting it allowed the xf86-video-ati driver to not care about these details, that were also not documented in the released official documents. There was a fair amount of free tools created to reverse-engineer the proprietary drivers, and they could be used to RE the AtomBIOS as well so initially RadeonHD actually worked better than xf86-video-ati ( https://airlied.livejournal.com/53129.html ).

But this was not sustainable. AtomBIOS is developed internally in the AMD/ATI and replicating it in RadeonHD with all the device-specific quirks was not possible. And eventually RadeonHD just died. xf86-video-ati is still being developed.

RadeonHD sources are still available for anyone interested: https://github.com/freedesktop-unofficial-mirror/xorg__dr...

Netgpu and the hazards of proprietary kernel modules

Posted Aug 3, 2020 18:32 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

I'd also add that not relying on AtomBIOS didn't mean RadeonHD was free of firmware dependencies - as far as I know all Radeon hardware has always needed firmware to be uploaded, but back in the day the firmware was just embedded directly into the radeon DRM kernel module instead of being pulled off disk. 70967ab9c0c9017645d167d33675eab996633631 changed that in 2009, but before that there was certainly still a firmware dependency all the way back to r100.