Radeon's ROCm OpenCL Runtime Finally Open-Sourced

[Zucca]

Unknown, but according to Stallman or other Free/Libre proponents it's like that. Suff in ROMs is ok, stuff loaded at runtime is not. Even if it is the same.

This has been puzzling me for quite a long time now.

Think about XeonPhi cards. They have a complete operating system (although open one, some intel Linux distro) inside them. Now imagine if those cards also contained a SSD, so that you don't need to "upload" the OS from the main OS you are running.
Now the "firmware" (and the whole OS) is contained inside the harware and is ok in FSF standards?
Using that same analogue: If graphics cards would contain flash chips that store heaps of data that run some overly complicated firmware that no-one (except few people) knows what it is doing... It's an 'OK' for FSF?

I'm personally ok with closed-firmwares, where ever they may reside. Open source drivers provide enough flexibility/hackability that community can utilize.

[darkbasic]

Guys I completely agree with you that free software isn't free anymore if you have to use firmware blobs, but let's celebrate this massive release for now

[bridgman]

Time for the usual reminder - the drivers work just fine without microcode images and do not rely on them in any way, it's the hardware that needs microcode to operate (since the microcode is part of the hardware design).

All the driver does is load the microcode images into the chip at power-on and generate an error message if something goes wrong (so you know why the hardware isn't working).

[artivision]

Time for the usual reminder - the drivers work just fine without microcode images and do not rely on them in any way, it's the hardware that needs microcode to operate (since the microcode is part of the hardware design).

All the driver does is load the microcode images into the chip at power-on and generate an error message if something goes wrong (so you know why the hardware isn't working).

Clarification for children: If something is loaded on the CPU and exist inside the CPU RAM or Cache, then is just the opposite from that you said. If it is loaded on the GPU and exists only inside the GPU RAM or Cache, then it is exactly what you said. If it can be replaced with driver code, then it is also the opposite from that you said. Basically if it is general code or can be general code, then you do something not very good. If it is necessary and real HW code then you are ok.

[Zucca]

@bridgman: I don't belong to any church or worship any gods, but I'll say this: Amen.

I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.

[bridgman]

Clarification for children: If something is loaded on the CPU and exist inside the CPU RAM or Cache, then is just the opposite from that you said.

So children get stricter rules. For adults the usual rule is "if something is executed by the CPU" not "if data is processed or copied by the CPU".

I don't have a problem with more stringent data standards for children, although GPU microcode would probably not be my first priority.

If it can be replaced with driver code, then it is also the opposite from that you said. Basically if it is general code or can be general code, then you do something not very good.

The microcode can not be replaced by driver code, other than the subset of the MEC microcode handling HW scheduling and for that we provide an open source alternative in amdkfd. We don't even try to work around the microcode during early bringup of emulated or real silicon, except to the extent that the hardware can run without microcode (eg you can run without SMU microcode but locked to low clocks, and you can run without UVD/VCE microcode if you are only using the 3D engine).

There are exceptions but in general the microcode controls hardware at a deeper level than what we expose via CPU-accessible registers.

If it is necessary and real HW code then you are ok.

It is necessary and real HW code.

[bridgman]

I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.

... and harder to maintain.

When we announced the Radeon Pro SSG products my first thought was "hey we can put microcode images on the SSD...".

My second thought was "... and then watch everyone scramble to redefine the rules again".

[RussianNeuroMancer]

https://github.com/fail0verflow/radeon-tools/tree/master/f32

People who want to see Radeon microcode content, what are you waiting for?

[darkbasic]

All the driver does is...

...nothing without the hardware, which in turn needs the microcode.

[smitty3268]

@bridgman: I don't belong to any church or worship any gods, but I'll say this: Amen.

I guess some people are satisfied only after manufacturers put a flash chip on to the card, load firmware from there and call it a day. In the end it's the same thing as now, but more expensive to produce.

The thing is, dungeon doesn't care about it. He uses the proprietary drivers anyway. This whole thing was just him trying to start a flamewar for whatever reason. I guess no good news can go without someone trying to shit all over it.

Personally, I feel like the UVD (video decode acceleration) firmware actually is high level enough to count as part of the driver software - but it's obvious why it's done that way, to allow them to keep their DRM stuff secret. The rest of the firmware, which is enough to run all the 3D acceleration bits, seems fine and on the hardware side of things to me.