Radeon/AMDGPU Firmware Binary Blobs Updated, Polaris Added

[phoronix]

Phoronix: Radeon/AMDGPU Firmware Binary Blobs Updated, Polaris Added

Hitting the linux-firmware Git tree are updates to the firmware/microcode binary-only images for the graphics cards supported by the Radeon and AMDGPU DRM drivers...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Radeon-Blob-Updates

[xeekei]

AMD seem to release new code everyday these days. I hope there'll be an affordable Polaris card soon.

[xpue]

So much for "open source".

[danieru]

Is there still ongoing effort to reverse engineer this? I would definitely buy a new AMD CPU and GPU if there's a some what usable firmware for the GPU, i think that's the last closed-source bit since AMD is now developing this exciting open-source driver for AMD video cards. I could replace my AMD Phenom 9600 with something faster for compiling, and my GTX 650 since nouveau isn't fast enough for 125 stable fps at OpenArena. It's amazing all the achievements that nouveau developers did, but I would rather go with AMD since their open-source driver is official.

[bridgman]

So much for "open source".

If you mean "so much for open source hardware" (the "blobs" discussed here are HW microcode which we run from on-chip RAM rather than on-chip ROM) that is true -- we never talked about opening up hardware designs. If you mean "so much for open source drivers" the drivers have been open source from the start.

We have tried a few times to get board vendors interested in loading the microcode images in BIOS code rather than in the driver, but haven't had much interest since (a) it drives up board cost and makes microcode updates more difficult, (b) it's very difficult to quantify the market for those boards.

[danieru]

If you mean "so much for open source hardware" (the "blobs" discussed here are HW microcode which we run from on-chip RAM rather than on-chip ROM) that is true -- we never talked about opening up hardware designs. If you mean "so much for open source drivers" the drivers have been open source from the start.

That's one way to look at it, but since it's loaded by the OS to on-chip RAM you could modify it (if it was open-source). I'm not asking AMD to open that. But I always wondered, what would happend if somebody write an open-source firmware, and then phoronix started making benchmarks and some people started using it? Would AMD make some crypto-signed bullshit like Nvidia did?

[danieru]

There is no reason to throw away GTX 650 because of useless nouveau driver. Nvidia 3xx seems to work fine with it like with other nivida cards after mx4.

https://www.youtube.com/watch?v=3O995Oc2TjA

nouveau actually hit 125 fps in openarena with medium graphics if I enable re-clocking. It's just that i have some little slow dows on some parts of some maps, and that sometimes take away the advantage that those 125 fps give me. nouveau it's usable and openarena with nouveau playable. Just not enough if you're competing. nvidia's closed-source driver is another option but gentoo is a little easier without binary blobs, so i would like open-source alternatives if they exist.

[juno]

There is a new blob that has not existed for chips before smc_sk.bin, same size as smc (s... memory controller?)
bridgman: is there a list for these abbreviations? Most of them are clear, some are not (for me)
Btw., can open source fans e.g. leave images out for hardware that they don't want to use, e.g. the VCE?

[SystemCrasher]

Offhand I haven't been able to find what's changed with these firmware blobs

That's what I dislike so much about blobs...

[bridgman]

I didn't see smc_sk.bin in the patches, where did you see it ?

Alex listed the blocks previously at https://www.phoronix.com/forums/foru...761#post459761 , quoting below:

SMC = System Management Controller
Handles power management

CP = Command Processor
Multiple sub blocks (ME, PFP, CE, MEC)
Handles 3D and compute command processing

RLC = Run List Controller
Handles misc stuff on the GPU (interrupts, etc.)

UVD = Universal Video Decoder
Handles video decoding

MC = Memory Controller
GDDR memory controller

The only new ones are VCE (which you know) and SDMA - the DMA controllers used to be just hard-wired logic but as the complexity went up we started using microcode there as well. Pretty much every complex chip from every vendor is full of microcoded state machines these days, the only issue is whether the microcode is executed from ROM or RAM.

The driver does not have logic to recognize missing microcode images and disable the driver functionality associated with that hardware - I supposed it could be added but doesn't seem like a great use of anyone's time.