The Updated AMD Polaris Firmware Blobs Needed For RX 480 Support Land

[boltronics]

Agree that that would make most users happy, and we have looked into it a couple of times. Problem is that in order for the alternate microcode to meet "free" criteria there would also need to be a toolchain allowing it to be modified and rebuilt. Once that toolchain was made available (or reverse engineered) the original microcode for that block effectively gets opened as well. We would not only need to implement alternate microcode but would need to build alternate chips with alternate hardware so that having a toolchain for alternate microcode does not put the original microcode at risk.

One way around that would be to have a dual BIOS/flash "slot" (or whatever term would be appropriate) where microcode can be uploaded to either of two slots on the flash - but with a catch. A hardware restriction could only allow the first slot can be used with signed and encrypted firmware from AMD. On the second slot, customers can go nuts. Here, free-software firmware can be installed and can be set to take precedence over the default microcode.

The biggest expense to doing this would be for the necessary increase in flash capacity to support two sets of microcode (which I'm guessing would be peanuts), and (more importantly) the implementation of the hardware restriction to manage "secured" access to the first slot. This idea also works on the assumption that the DRM-compatible microcode is only ever released in its encrypted form.

I'm sure that sounds like a lot of work, and there might be things I'm overlooking... but it sounds doable. Even if such a feature was only provided on AMD's most high-end consumer cards, I'm sure people would buy the card just for that sort of feature.

[drSeehas]

Wasn't PSP already included in “Beema” and “Mullins”?

Yes, PSP is included in Beema/Mullins, but not in Kabini/Temash.

[drSeehas]

Yes, and also in CZ/BR.

... and also in Stoney Ridge.

[bridgman]

i read this in this way: AMD is waiting for someone who reverse engineering their microcode so they can open up the microcode in the end because there is no more secret to keep...

No, that's exactly the wrong way to read it. Remember the "no" gif from another thread ?

One way around that would be to have a dual BIOS/flash "slot" (or whatever term would be appropriate) where microcode can be uploaded to either of two slots on the flash - but with a catch. A hardware restriction could only allow the first slot can be used with signed and encrypted firmware from AMD. On the second slot, customers can go nuts. Here, free-software firmware can be installed and can be set to take precedence over the default microcode.

Signing isn't the main problem here - it's that microcode has to run on something, either a HW state machine or a simple processor, and once you provide the information to write new / changed microcode to run on that <whatever> then you immediately enable reverse engineering of the original microcode. The only way around that is to have different *hardware* under the microcode, which means different chips.

EDIT - thinking about it a bit more, if we got to the point where signing was the last remaining issue then your suggestion would be a good way to get "human input" to OK bypassing the security mechanisms, so still a good idea.

[bridgman]

That reminds me of the following:

clinfo segfaults when I set my machine to this combination: linux-4.7rc-amdgpu.ko + mesa-git-opengl + amdgpu-pro-opencl.

Isn't amdgpu-pro's OpenCL supposed to work with the non-pro amdgpu.ko kernel module?

No - OpenCL and Vulkan need kernel driver functionality that we can't push upstream yet because we don't have an open source userspace driver that needs it. At the moment I believe you can run the closed source OpenGL over an upstream driver but not OpenCL or Vulkan.

You'll hear people saying that amdgpu pro is "just a userspace addition" but we have always described it as a different stack from the all-open one.

[bridgman]

Not shills, paying AMD customers who had lousy GPU driver support length for both Windows and Linux. If AMD wanted to stick the finger to their customers to save a couple of dollars on a reasonable support time length for their drivers then on their head be it.

Hi Slartifartblast,

I'm trying to make a connection between your post and the microcode topic without success - are you saying that driver support would be better if we did something different with the microcode ? If so can you explain how (most of the complaints seem to focus on soft-loading vs building into the chip) ? I'm not getting it...

Thanks...

[Slartifartblast]

Hi Slartifartblast,

I'm trying to make a connection between your post and the microcode topic without success - are you saying that driver support would be better if we did something different with the microcode ? If so can you explain how (most of the complaints seem to focus on soft-loading vs building into the chip) ? I'm not getting it...

Thanks...

It appears you have difficulty comprehending the rebuttal of legitimate criticism of AMD and those that do must be a shill. I have never been paid to advocate for or against AMD, have you ?

I just happen to be a person who has indirectly been paying your wages by being a (former) customer of AMD and been burned by the experience. Jees, AMD the listening company.

[bridgman]

Thanks, but I still don't understand how your original comment relates to microcode. I wasn't the one who called people complaining about Skylake (or our) microcode "shills", that was someone else (and obviously not an AMD employee).

If you are saying that your comment has nothing to do with microcode that's certainly fine, but the "shill" comment you responded to *was* directly related to microcode delivery AFAIK. I haven't seen it used in any other contexts except for one person who chose "shill" as his/her user name on the site.

[Slartifartblast]

Thanks, but I still don't understand how your original comment relates to microcode. I wasn't the one who called people complaining about Skylake (or our) microcode "shills", that was someone else (and obviously not an AMD employee).

If you are saying that your comment has nothing to do with microcode that's certainly fine, but the "shill" comment you responded to *was* directly related to microcode delivery AFAIK. I haven't seen it used in any other contexts except for one person who chose "shill" as his/her user name on the site.

QED, AMD the listening company.

Stay in engineering and don't ever consider a job with AMD PR, you'll only make things worse.

Microcode loading is a moot point if I cannot trust AMD to support their GPU products for a reasonable length of time.

[Pontostroy]

No - OpenCL and Vulkan need kernel driver functionality that we can't push upstream yet because we don't have an open source userspace driver that needs it. At the moment I believe you can run the closed source OpenGL over an upstream driver but not OpenCL or Vulkan.

You'll hear people saying that amdgpu pro is "just a userspace addition" but we have always described it as a different stack from the all-open one.

I had the opposite experience, opencl works fine(blender, darktable), even vulkaninfo works, but any opengl apps segfault.

http://www.gearsongallium.com/?p=2960