Radeon/AMDGPU Firmware Binary Blobs Updated, Polaris Added

[juno]

Thanks

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.

Agreed (this could be done by some foss fans, too, couldn't it)

smc_sk.bin is only for Polaris10 and 11:
http://git.kernel.org/cgit/linux/ker...aecbdf09a6c61e

[bridgman]

Agreed (this could be done by some foss fans, too, couldn't it)

It gets messy very quickly these days though, since (for example) power management needs to know if a block isn't going to respond to power gating messages (no microcode = dead block)... certainly not impossible but it would add complexity in some of the most complicated parts of the driver.

[darkbasic]

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.

That would be useless since people searching for blob-free firmwares are the very same one who search for a libreboot enabled laptop: your card will simply not work with libreboot.

[Vyrlokar]

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.

You mean GPU vBios or mobo bios? I assume you mean GPU vBios, because otherwise it would be akin to asking x86 bios vendor to include the binary blobs for all GPUs in the universe...

[soulsource]

Use the . run file from nvidia site, kill X or reboot to linux rescue mode and as root run the installer. Before installing do have kernel headers and compiler tools installed.

Then get a gun, point it at your own foot, and fire.
Gentoo is a rolling release distribution, using the nVidia provided installer is a guaranteed way to run into incompatibilities when updating the system, as it exists outside of the package manager's dependency tracking. To avoid those issues, the recommended way to deal with the proprietary drivers is to use the ebuilds made for them instead. More details can be found on the Gentoo Wiki's article on proprietary nVidia drivers.

[DanL]

Offhand I haven't been able to find what's changed with these firmware blobs with the commit messages just mentioning their internal Git revision ID.

The size of the UVD blobs changed, so my guess would be something with that.

[Serafean]

Then get a gun, point it at your own foot, and fire. Nobody guarantees that packaged drivers are tested and patched at least in debian testing that is also a rolling release distro. Packaging is extra unnecessary step that can cause bugs. And you can use latest kernels, nvidia has been behind couple times coupe of weeks and I had to manually patch. Sure in gentoo too you must reinstall the driver for example when you update xorg. It is not a big job download latest driver from nvidia site same day as it is released. It may take weeks before your distro has packaged the driver, so it is better way install a display driver outside of the packaging system.

You're wrong, let me explain why :
1) Gentoo has a system to have libGL from mesa and blobs installed side by side, with almost runtime switching. using the install.sh from nvidia directly breaks this spectacularly
2) using non-packaged drivers means the package manager has no track of the files it installed, thus maybe leaving random files behind. (not good...)
3) In gentoo you must reinstall the driver (almost) every time you twiddle with your kernel. That's a major PITA (granted, packages don't help there)
4) Even in debian I wouldn't recommend being outside the package manager, if only for DKMS (apt-get update, you get a kernel upgrade and no more X windows, this doesn't sound too nice)
5) nvidia doesn't guarantee that non-packaged drivers are tested and patched for your distro. With the package you can reasonably suppose at least one person tried it on the same distro.

Experience part :
6) the gentoo nvidia packagers are awesome, haven't seen a delay longer than 3 days from official release to packaged in the last few years (including legacy drivers).

[Serafean]

Guest thanks, forgot about that... that makes +1 for the package manager

<QUOTE>Closed microcode is downloaded to the hardware, has essential functionality [...]</QUOTE>But that's the whole point we're discussing here : what is the functionality? Is it good for me, or is it spying on me? No way to know.
This being said, I applaud AMD for their efforts, and seeing the rest of the world am pretty much satisfied with the current opensource state.

[Serafean]

debianxfce Ok, you're talking about how to do stuff and why it happens, I'm talking about my personal comfort (not needing to remember to run commands at specific times, keeping the system managed etc...). I'm leaving the .run discussion here.

As for microcode, let me expand your argument : "Normal people are not programmers, so there are no benefits to have programs as opensource."
I'm not trying to convince you or anything, just trying for you to understand the other side's point of view.

[duby229]

Sure gentoo dependencies has same flaws than in debian, when you want to uninstall xorg-nouveau, it will remove all xorg drivers. They do not much think about dependencies for uninstalling. So a software can happily live without package manager. You can find graphics drivers files easily and use dkms directly.

I don't want to play a game of quoting, but I want to say this: Gentoo uses a tool called eselect that totally solves that problem. There is zero point to install graphics drivers on gentoo outside of package management.