Interstellar Marines On Linux With Catalyst: Bull S*#@

[dungeon]

Who honestly cares if the hybrid stack is there when you use normal distro installers? If the OSS one is fast enough and boots you in a stable fashion to desktop, you can do whatever you want. Also it's not like it's that hard to make custom installers yourself if you really really need the hybrid stack immediately after installation

I only describe as information what distro i use will probably do with amdgpu driver... with in mind that Debian does not ship any firmware blobs by default or anything from contrib/nonfree repos, thus not even firmwares used by radeon driver... let alone what will happen with amdgpu driver where are only more blobs as an option... of course there are other ways around, unofficial images with those, etc. everything is doable of course, but that only user can decide on that - which in my mind is considered - what is *fine*

So it is not about me (i use radeon driver for years), it is about distro i use and how amdgpu driver align to that.

[duby229]

Well, ok. But you can't run the driver without an actual hardware GPU either, and I doubt you'd say there is a physical GPU inside the kernel.

It's probably more accurate to say that the hardware relies on some binary blobs still, even if you use the open source driver in the kernel.

That's fair enough. Just ftr I don't have any problems with the oss drivers. I think they're fantastic.

[duby229]

For the record, I'm only boycotting "out of the box" / "out of box" because there's a good chance no two adjacent people will agree on what it means. The rest I can live with although I hate seeing people describe microcode as firmware just to make you think it's running on the main CPU.

Sorry, I have heard you say that before. I should probably start replacing the word firmware with microcode. It's going to be difficult though, because most folks use the word firmware. In gentoo at least, the folder they are installed in is called firmware, the package they are installed from is called linux-firmware. I guess it's just what I've been using because that is what I've seen.

[bridgman]

Sorry, I have heard you say that before. I should probably start replacing the word firmware with microcode. It's going to be difficult though, because most folks use the word firmware. In gentoo at least, the folder they are installed in is called firmware, the package they are installed from is called linux-firmware. I guess it's just what I've been using because that is what I've seen.

Yeah, what complicates things is that *some* of the stuff running on hardware arguably *is* firmware (eg a network chip with a serious CPU on it running part of a network stack and probably a teeny tiny OS) -- but there's a continuum with "obviously microcode" at one end and "probably firmware" at the other end and no clear dividing line between them.

In fairness to the distros, the first "runs on the hardware" images they had to deal with were probably network chips so it's understandable how the folder got its name. GPU bits tend to be closer to the "obviously microcode" end (heck, even our memory controllers are microcoded) but I think they showed up in the distros later later.

[nanonyme]

Yeah, what complicates things is that *some* of the stuff running on hardware arguably *is* firmware (eg a network chip with a serious CPU on it running part of a network stack and probably a teeny tiny OS) -- but there's a continuum with "obviously microcode" at one end and "probably firmware" at the other end and no clear dividing line between them.

In fairness to the distros, the first "runs on the hardware" images they had to deal with were probably network chips so it's understandable how the folder got its name. GPU bits tend to be closer to the "obviously microcode" end (heck, even our memory controllers are microcoded) but I think they showed up in the distros later later.

Then again, from a paranoid point of view it does not really matter. Executed code you can't audit is always suspicious no matter which processing unit it is run on. Granted, there could be hardware backdoors but that is precisely why this push at openness will most likely not stop until both mainstream software and hardware are open and can be audited by anyone

[dungeon]

Then again, from a paranoid point of view it does not really matter.

You definitely should care.

The aim of this talk is to provide insight to the security, architecture and yes you guessed it, vulnerability of the AMD System Management Unit (SMU) firmware found in modern AMD x86 processors.

I guess those microcode update last year has something to do with this, even there is no changelogs

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=8ac569dd3ca3ca685bd47ee86c1eeb6050864db3

[dungeon]

I guess i am safe now . Bridgman as i have Kabini, how i can know that fixed AGESA is used for my latest bios or whatever

[smitty3268]

Fwiw will the two stacks be parallel installable or will you have to remove one to install the other?

NVidia has been working on updating how linux handles OpenGL to allow multiple vendor implementations to be installed at once. Until that proposal gets implemented, it won't work. Once that goes out, though, i'm guessing AMD will fix their stacks fairly quickly.

[curaga]

In AMD blob time, "fairly quickly" is equivalent to Valve time, being a time between three (3) and fourteen (14) years.

[calexil]

Oh my that is an old picture. please remove it.