AMD Releases Microcode For All GPUs

[phoronix]

Phoronix: AMD Releases Microcode For All GPUs

In the next step towards open-source 3D support for the R500 and R600 GPUs (Radeon X1000 and Radeon HD 2000/3000), AMD has just pushed its production microcode into the Mesa/DRM git tree. This is the microcode found in the fglrx driver and it covers the Radeon R100 to R600 product families.

http://www.phoronix.com/vr.php?view=12055

[sreyan]

I think these efforts are certainly appreciated by the community.

[fragro]

Wow! I'll only buy AMD/ATI in future! :D

[Melcar]

Excellent news.

[fragro]

Is there still some work/activity based upon the new docs in Mesa repository?

[d2kx]

Really insane how fast the new releases are getting out for the developers... this is one of a few reasons why I only buy AMD/ATI products, they deserve every kind of support.

[bridgman]

Yes, but so far the work is happening in private branches -- the 3D work is still at the early stages so don't think anything has been pushed to master yet. If you monitor #radeon and watch for discussions between simpsonc, airlied, agd5f, glisse and others you'll have the very latest news ;)

[fragro]

My next Notebook will be one based on Puma plattform! I hope the manufactors will build some qualtity notebooks with this.

[ioannis]

AMD with their open-source philanthropy

not a good use of the word 'philanthropy'. I know you mean 'generosity', but philanthropy is more towards humans (help those in need). Unless of course if you mean that the open-source developers are 'dying' to get this information and thus AMD, with their actions, save their lives :-P

[edged]

This is very good, but I never hear specifically stated for the higher parts - like what about the RV670 (3870)?

TBF I have not scoured through the releases, but a person only looking at the newsies on websites would get the impression of only the lowend parts being "opened up".

Would someone please clarify?

[fragro]

Afaik the R600 3D documentation in one of the next candidates. Please confirm!

I have a Radeon X700 (r410) in my Notebook and i am very happy that the "low end" documentation is released.

[bridgman]

RV670 microcode was included in today's release, along with RV620 and RV635. For the register specs, tried to pick one chip which was representative of the entire family, since the registers are pretty much the same across all the variants. We went with the docs for mobile parts (mobile uses more features of the chip). Going with a mobile part means choosing a low end or midrange GPU, but it doesn't matter since the registers are the same anyways.

There are a couple of exceptions, like the RV515 memory controller registers having a different offset than the rest of the R5xx family. The latest parts (rv620/635) are also significantly different so we have one of those docs in the queue for cleanup and public release (the radeonhd devs have the info under NDA already).

[bridgman]

frago, R600 3D is next on the list but there is still a fair amount of work to be done on the document.

[stan]

I really appreciate AMD's support of open source drivers, and will recommend AMD graphics cards and processors whenever I have the opportunity!

[sid350]

so what about RC410?
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]

[fragro]

frago, R600 3D is next on the list but there is still a fair amount of work to be done on the document.

I see there is many work to do, but i am glad that documentation/implementation is going on. In deed we has to spent respect these Developers which have still a lot to do now!

[fragro]

so what about RC410?
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]

Afaik this chip is very special and makes developers strange headage. (sorry i don't know where i read this)

generic informations are here:
http://dri.freedesktop.org/wiki/ATIRadeon (http://dri.freedesktop.org/wiki/ATIRadeon#head-6cd1522552beb3e7ad5489538ba676bbce863c87)

[bridgman]

The RC410 3D engine is covered by the R3xx 3D register spec we released (last week ?), and most of the remaining hardware was covered by the original R200-era documentation. There are still a few gaps in the documentation but they're getting smaller.

The integrated parts were a pain for the developers because they didn't have programmable vertex shaders and so the 3D engine needed to be set up differently. Without docs that was *really* difficult -- with docs it's just difficult ;)

The RS780 (aka 780G) graphics core seems to have all of its shaders intact, so there should be some happy 3D developers once they get around to working on the 780.

[edged]

RV670 microcode was included in today's release, along with RV620 and RV635. For the register specs, tried to pick one chip which was representative of the entire family, since the registers are pretty much the same across all the variants. We went with the docs for mobile parts (mobile uses more features of the chip). Going with a mobile part means choosing a low end or midrange GPU, but it doesn't matter since the registers are the same anyways.

There are a couple of exceptions, like the RV515 memory controller registers having a different offset than the rest of the R5xx family. The latest parts (rv620/635) are also significantly different so we have one of those docs in the queue for cleanup and public release (the radeonhd devs have the info under NDA already).

That makes sense and hey thanks for the info and a fast response. :)

[BlueKoala]

I'm really excited about this :D
I bought a HD3650 DDR2, the hardware is more than just great for the price, now it seems the support will follows. I can't wait for the day where I can say "Yeah, AMD is much more bang for buck AND has more support"
Things sure seem to be heading that way and fast with everyone working on their own driver claiming their method is better for whatever reason. The only clear winner here is the consumer. =]

[werdz]

*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.:)

[kingos]

Following the progress at http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=summary

just want to say, go go go :-)

[bugmenot]

Microcode isn't source code AMD. Not acceptable.

[bridgman]

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.

[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???:D

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

[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...

[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.

[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!

[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.

[arekm]

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

[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 ;)

[dungeon]

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