No, AMD Will Not Be Opening Up Its Firmware/Microcode

[bridgman]

Afaik, ATI has not resumed this level of documentation, they actually have only further increased their dependence on extra layers and encapsulation with atomBIOS and DAL.

You should be happy about the new DAL code... I'm told it makes less use of AtomBIOS than the current driver code -- on the other hand it needs a fairly large team to write and maintain the code, which is only feasible if the code is shared across multiple OSes (which in turn needs some abstraction).

Yes, you get that, or used to get that, for most of the AMD hw. You only got some of that sort of information for just a small time window for ATI hardware, and only so because we, those evil corporate microsoft drones (if you believe the people who forked radeonhd), requested this at the right time, in the right way, from the right people (being AMD, the party of the AMD/ATI conglomerate which wanted open source drivers).

Luc, one more time... I never even *saw* your proposal until ~9 months after the project started. We have discussed this multiple times.

I wrote the proposal that was approved and funded, with input from GPU-side architects plus some CPU-side people also named John (presumably their input was based on your proposal). At a high level the two proposals were pretty much the same the same (enough for SUSE to be told their proposal was going ahead) but they actually differed in a number of ways (3D focus, use of AtomBIOS, AMD hiring developers, AMD sanitizing & releasing docs etc...) that would only be obvious to someone who *really* cared about those details.

Obviously if I had *known* there were two different proposals I would have discussed that with you at the start, but I only found out about the detailed SUSE proposal much later, and didn't find out that SUSE had been told their proposal was accepted until well into 2008, during a call with your VP. It didn't seem like anybody screwed up, just the kind of unfortunate disconnect that sometimes happens if you have enough people involved.

I don't remember what my first thought was when I found out (other than "oh crap") but "no wonder Luc was angry all the time" had to have been right up there. You can continue to paint me as some kind of super-villain for as long as you want but it's been almost 10 years... probably time to give it up.

[bibaheu]

coder111 and bibaheu: it's too late, in both cases. That ship sailed a long time again, and feel free to thank Mr Bridgman and the people who forked RadeonHD for it.

At least nowadays we can use GPUs just for rendering and leave the output signals to other devices. That's what I am doing currently, my Radeon 290x doesn't have VGA output, but I am using PRIME to use the integrated Intel GPU to drive my secondary VGA-only monitor

[bridgman]

It seems that documents for Volcanic Islands and Polaris are missing

The ISA guide was published as GCN3 rather than Volcanic Islands.

Polaris had essentially no driver-visible changes relative to VI; I think one extra register was added.

[dungeon]

Yup it is VI doc or GCN3 or GCN 1.2 or GfxIp8 or whatever, you name it

[bridgman]

The great thing about standards (naming conventions in this case) is that there are so many to choose from

[dungeon]

Only i am not sure quite for Polaris and GfxIp namings... I just guess 10/11 coming from GfxIp convention

[starshipeleven]

RISC-V is a CPU architecture and not a GPU one.

CPUs have the same issues we have on GPUs, and if open design catches up for CPUs someone will start thinking about open design of GPUs too.

[starshipeleven]

you are the one who should be punished because of your push to punish people for only free speech .

The same applies to you that want to punish me because I used my free speech to say he should be punished.

[H3g3m0n]

RISC-V is a CPU architecture and not a GPU one.

It's an ISA, not really architecture. And a GPU is a special purpose type of CPU. With a large number of simple cores and some special purpose pipelineing and instruction sets for performing special instructions like matrix operations massively in parallel and so on.

The thing about RISC-V is it's about ready to explode over the next few years. There's some key components such as self booting specifications, privileged ISA and so on that need to be locked into place. But then there will suddenly be a bunch of open source processor designs around that anyone can grab and get fabbed.

Those people will be looking around for companion cores such as video and there will be a large incentive to develop that stuff. lowRISC are already working on basic VGA.

There are also going to be people working on the parallel side of things, many core CPUs, tensor processing units, MIAOW, and so on.

Obviously full proper GPU hardware acceleration is quite a way off, but it's on the horizon. There is also the issue of fabrication.

[RussianNeuroMancer]

Hi,
Yes, there is: https://bugzilla.kernel.org/show_bug.cgi?id=51381
And Alex added code to the kernel to blacklist this specific card by PCI ID and disable dynamic power management for it. (Thanks to Alex for quick response by the way). Which made my system usable, but still I wish dynamic PM worked. From time to time I recompile the kernel and remove my card from the quirks blacklist just to see if the error is still there. It is still there...
My card is in an Asus laptop. What make is yours?

Ok, I don't dynpm issues here, dynpm works for me. however runpm broken for me too on Acer 7560G with 6620G+6650M. I doesn't even research this properly because I thought motherboard was broken in some funky way.

That what I seen on my laptop:
When manual switch via vgaswitcheroo was implemented and became available in regular kernels it worked for me and was able to power on dGPU properly.
Some time later, maybe with runpm shipping, I not sure, it stopped working, and I even filled bugreport about this on freedesktop, which turns out to be probably invalid.
Now it's getting interesting - it turns out to be invalid because Alex asked me to check fglrx, and fglrx wasn't able to power on disabled dGPU too! That works earlier with previous fglrx (like with earlier vgaswitcheroo) but since my motherboard was replaced once and new motherboard was shipped with BIOS 2.0 which is not even published on Acer web-site, I conclude that is issue more likely will be on motherboard side (hardware issue or BIOS issue) than on both of kernel and fglrx side.

Now I even don't know what to think about this.