*Wow*. Fair play to AMD/ATI for all of this. The rate at which they're pushing out specs is amazing, and they've certainly shattered a few negative opinions of them in the last while.
Announcement
Collapse
No announcement yet.
AMD Releases Microcode For All GPUs
Collapse
X
-
Following the progress at http://gitweb.freedesktop.org/?p=xor....git;a=summary
just want to say, go go go :-)
Comment
-
My understanding is that microcode blobs are accepted, although there is some discussion about having the microcode blobs loaded from user space to avoid the kernel getting too big. I don't think anyone is publishing microcode source today.Test signature
Comment
-
Originally posted by bugmenot View PostMicrocode isn't source code AMD. Not acceptable.
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!!
Comment
-
Originally posted by bugmenot View PostMicrocode isn't source code AMD. Not acceptable.
Comment
-
Originally posted by Ex-Cyber View PostMicrocode 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...
Comment
-
Originally posted by agd5f View PostThe 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.
Comment
-
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.Last edited by bridgman; 22 March 2008, 02:22 PM.Test signature
Comment
Comment