"Ask ATI" dev thread

[static_drc]

@energyman Intel integrated video card drivers have no undocumented binary sections of microcode. They work very well with free software drivers. So do integrated video cards from VIA. As for AGP/PCI cards, the 3dfx Voodoo series works well with free software drivers, but they are not so powerful and are hard to come by nowadays.

Do you know if there are difficulties in the release of the documentation of the Radeon CP microcode? What are the difficulties?

Thank you!

[energyman]

static_drc I said CPU not GPU.

If you are 'Hardcore' about GPUs you have to be hardcore about CPUs as well - which rules out intel. Or AMD (who do the microcode updates via bios), and probably via too.

[bridgman]

However, do you know if there are any specific problems with getting the Radeon CP microcode in a non-blob and documented format? Has ATI said they have any problems with this in the past, and has anyone asked them?

I guess the first thing I should mention is that I work for ATI/AMD and (among other things) organize the technical reviews of information we hope to release.

At the start of the open source graphics project one of the tasks was working out the overall approach -- which areas would be most useful to developers, which areas posed the highest risk for us, and what combination of information would let us support the development of good free drivers without posing an unacceptable risk in the other markets where we sold the same products (ie other OSes). Opening the microcode was identified as one of the highest risk areas, with no apparent benefit (since other GPUs also use microcode in the same way but either hide it on the chip or load it transparently from ROM at power-up).

I don't want to go into details, but the problem in a nutshell is DRM. On other platforms, we are obligated to deliver secure and robust DRM implementations (Digital Rights Management), and that becomes much more difficult if we expose any of the hardware internals other than the driver programming model (registers and command packets). This is also why we have not released information in areas such as the UVD video processor. Again, the risk is not what could be done with Linux, but what could be done with the information on other OSes.

The open source graphics project was basically built on the idea that we could open up enough information to allow the development of fully free drivers *without* revealing enough information -- either directly or by "moving the starting point for reverse engineering" -- to put our products at risk in other markets. So far the project has been well received, and hopefully we can depend on the free software leaders to treat all non-free microcode equally, whether it be loaded by the driver or burned into the chip.

[static_drc]

@energyman I am so sorry! I misread what you said. AMD and Intel CPUs work fine with the Linux-libre kernel, which only contains free software.

Do you know if there are any problems with ATI releasing the documentatin for the Radeon CP microcode? What are the problems?

If this is a difficult question, or if this is not the right place to ask, then please let me know.

EDIT: I'm sorry! My question was answered while I was typing my reply. I really appreciate you taking the time to answer my question. I now understand the reasons for keeping the microcode the way it is. I continue to support ATI in how much they contribute to the free and open source software community. Thank you!

[bridgman]

static_drc, I think the reason the CPUs work with Linux-libre is that microcode patches are *usually* applied by the BIOS at system startup, before the kernel runs. Microcode loaders were added to the kernel in order to simplify system maintenance and improve reliability; removing them from the kernel means that the user either runs with older CPU microcode or is forced to flash their BIOS image with a new blob to get the latest microcode.

Taking CPU microcode blobs out of the kernel doesn't get rid of them, it just forces them to be managed in another (less convenient) part of the system.

[nanonyme]

Taking CPU microcode blobs out of the kernel doesn't get rid of them, it just forces them to be managed in another (less convenient) part of the system.

Actually iirc Linux kernel 2.6.29 allows loading of the CPU microcode on-boot via the kernel. I've understood this is a new feature since I didn't see it in the CPU config section earlier but I did notice it there while trying out 2.6.29. (While the AMD microcode didn't even seem to apply for my CPU. Meh) The idea might be that while you do need some kind of microcode to boot at all, you get a more up-to-date version of the microcode when the system starts. If you want to check what I mean, look for symbols MICROCODE_AMD and MICROCODE_INTEL.

[Nille_kungen]

so beginning with Cat 9.4 all monthly Catalyst drivers will only support 6xx and up. This applies to all OSes.

Separately, we plan to provide quarterly updates for Windows off the legacy branch, but that will mostly be fixes for security issues and maybe newly released apps/games. No support for new OS releases.

Well doesn't the 9.3 driver add official support for windows7 ?
So windows users get windows7 support before they get "No more new OS support".

[bridgman]

AFAIK the Win7 driver API (WDDM 1.1) is for 6xx-and-up products only since it requires DX10 support.

[bridgman]

Actually iirc Linux kernel 2.6.29 allows loading of the CPU microcode on-boot via the kernel. I've understood this is a new feature since I didn't see it in the CPU config section earlier but I did notice it there while trying out 2.6.29. (While the AMD microcode didn't even seem to apply for my CPU. Meh) The idea might be that while you do need some kind of microcode to boot at all, you get a more up-to-date version of the microcode when the system starts. If you want to check what I mean, look for symbols MICROCODE_AMD and MICROCODE_INTEL.

Yep. My understanding, though, is that a couple of "totally free" Linux projects take the CPU microcode and associated loaders out again.

As you can imagine, there is a lot of debate about this, and some *very* long email threads

[Nille_kungen]

AFAIK the Win7 driver API (WDDM 1.1) is for 6xx-and-up products only since it requires DX10 support.

Well i didn't know that.