AMD Releases Microcode For All GPUs

[oibaf]

Hm, in this thread it looks like the microcode stuff isn't so hard secret and complicated stuff. Now that Debian put the nonfree firmware out of the default repository, it would really be cool to have free firmware, like nvidia has. Could reverse engineering be allowed, at least for the non-drm-capable hardware?

Totally agree with you. It would be nice indeed.

[bugmenot3]

Hm, in this thread it looks like the microcode stuff isn't so hard secret and complicated stuff. Now that Debian put the nonfree firmware out of the default repository, it would really be cool to have free firmware, like nvidia has. Could reverse engineering be allowed, at least for the non-drm-capable hardware?

[dungeon]

R6xx 3D docs is out, so what's status of this checking? That blob is different from old blob, or not?

[bridgman]

Before we released the microcode and Alex updated the DRM code, R300 microcode was being used for the R4xx, 5xx and 6xx GPUs (although nobody was running 6xx with the command processor yet). We mostly wanted to make sure that we had the right microcode out there and being used.

I doubt we ever tried running R4xx or R5xx parts with R3xx microcode so it's hard to say what bugs are fixed. The main change I would expect to see is fewer mysterious GPU hangs. I haven't checked if the microcode we pushed for R100/R200/R300 was any different from what was already being used -- I'll put it on the list of things to do *after* we get R6xx 3D docs out

[arekm]

Is there any info about what important new microcode fixes for each rXXX ?

[bridgman]

The microcode is loaded by mesa/drm, and was stored there. The -ati driver uses the Command Processor (which runs the microcode) if DRM is there, and uses the slower MMIO paths if DRM is not there.

I'm not 100% sure, but I think DRM previously contained microcode for R100/R200 which had been released by ATI and R300 microcode which had been "reverse engineered" from the fglrx driver. The R300 microcode was being used for 4xx and 5xx as well, which worked OK but probably introduced a few bugs which the new microcode should fix.

As Alex said, the microcode determines how the command packets ("PM4 packets", described in the R5xx 3D Acceleration document) are parsed, ie the microcode allows the chip to behave the way we documented it.

[orra]

The microcode is nothing more than a packet parser. For the most part you can program the the accel registers directly via MMIO, but it's much less efficient.

Ah. I was wondering about this. When I read the microcode blob was released, I was a bit confused. All this time the xorg-video-ati driver has worked without this microcode (I presume, because redistribution wouldn't have been allowed), so I was wondering what the need for it was. Speed, you say!

[agd5f]

Microcode source would probably be useless without a whole new layer of tools and documentation (I only say "probably" on the outside chance that it's using some standard ISA, which has been done in the past for at least one other vendor's "microcode"). It might be interesting to look at, but in a practical sense it's more part of the hardware than part of the driver. It doesn't run on the host CPU, and the hardware doesn't behave as documented without it. Besides, the role of the Radeon CP microcode seems to be pretty limited in scope unless I'm grossly misunderstanding something. Even FSF/GNU is not actively calling for this kind of stuff to be released, as far as I know...

The microcode is a little program that runs on the command processor and tells it how to parse up the incoming command packets. These packets are used to program the acceleration engines. The CP decodes the incoming packets and then programs the accel registers to do the appropriate thing. The microcode is nothing more than a packet parser. For the most part you can program the the accel registers directly via MMIO, but it's much less efficient.

[Ex-Cyber]

Microcode isn't source code AMD. Not acceptable.

Microcode source would probably be useless without a whole new layer of tools and documentation (I only say "probably" on the outside chance that it's using some standard ISA, which has been done in the past for at least one other vendor's "microcode"). It might be interesting to look at, but in a practical sense it's more part of the hardware than part of the driver. It doesn't run on the host CPU, and the hardware doesn't behave as documented without it. Besides, the role of the Radeon CP microcode seems to be pretty limited in scope unless I'm grossly misunderstanding something. Even FSF/GNU is not actively calling for this kind of stuff to be released, as far as I know...

[smlbstcbr]

Microcode isn't source code AMD. Not acceptable.

Source Code???????
They are releasing their specs + microcode, not opening their driver source code!
BTW, do you know what exactly are ucode and specifications???

PS: Great work/news from AMD/ATI despite their delicate situation, hopefully they'll get up and kick ass!!