Radeon Software 18.20 Stable Released With Official Ubuntu 18.04 LTS Support

[geearf]

OK, apparently the newer microcode may not work with the radeon driver, which is still the upstream default, so still some work to do before they can be upstreamed.

Oh I see, that makes sense.
Would it not be feasible to ship both maybe with a different name? The Linux tree already has 2 sets for Tahiti, one upper and one lower case, I assumed that was the reason.

[bridgman]

Would it not be feasible to ship both maybe with a different name? The Linux tree already has 2 sets for Tahiti, one upper and one lower case, I assumed that was the reason.

Yep, either different name, different path, or make the radeon driver work with the new microcode.

I was under the impression that radeon used "different case" ucode files from amdgpu (IIRC one has headers, the other does not) but last time I looked was a year or two ago. If it rains tomorrow I'll go catch up.

[geearf]

Yep, either different name, different path, or make the radeon driver work with the new microcode.

I was under the impression that radeon used "different case" ucode files from amdgpu (IIRC one has headers, the other does not) but last time I looked was a year or two ago. If it rains tomorrow I'll go catch up.

That's so nice of you, thank you!
I think I remember reading the same explanation about headers from Alex, not sure though.
If that's the case though, wouldn't that mean that we already have one firmware for radeon and one for amdgpu and so the fact that radeon has problem with the newer ones is not an issue and just an oversight?

[bridgman]

If that's the case though, wouldn't that mean that we already have one firmware for radeon and one for amdgpu and so the fact that radeon has problem with the newer ones is not an issue and just an oversight?

Yep. That's what makes me think it's not the case...

[geearf]

Yep. That's what makes me think it's not the case...

It's far from raining, at least here, so I'll eagerly wait for your answer tomorrow

[Nitrogen]

If I understand correctly driver stack released does not pertain to the Raven Ridge APUs, right? I'm asking because for Windows driver package 'Product Family Compatibility' explicitly includes AMD Ryzen CPUs with Vega Graphics, while this one doesn't. If so that's real shame, because I've been struggling to get my Ryzen 5 2400G to work since it came out in February. And no amount of BIOS updating/kernel switching helped.

[bridgman]

It's far from raining, at least here, so I'll eagerly wait for your answer tomorrow

It rained quite heavily here, so...

There are separate radeon and amgpu paths for firmware, but the amdgpu driver only uses amdgpu paths for VI and up. For SI and CIK the amdgpu driver uses the radeon paths.

I was looking at the MODULE_FIRMWARE lines in each driver, but in hindsight it would have been faster to look at the radeon and amdgpu folders inside /lib/firmware. There are no SI or CIK microcode images in /lib/firmware/amdgpu.

[geearf]

It rained quite heavily here, so...

There are separate radeon and amgpu paths for firmware, but the amdgpu driver only uses amdgpu paths for VI and up. For SI and CIK the amdgpu driver uses the radeon paths.

I was looking at the MODULE_FIRMWARE lines in each driver, but in hindsight it would have been faster to look at the radeon and amdgpu folders inside /lib/firmware. There are no SI or CIK microcode images in /lib/firmware/amdgpu.

yes I know all that
The question was about the 2 Tahiti (or other) sets in the radeon folder. We guessed one was for amdgpu and one for radeon, but no clue why the one for amdgpu isn't up to date with the one in the pro package.

[bridgman]

The question was about the 2 Tahiti (or other) sets in the radeon folder. We guessed one was for amdgpu and one for radeon, but no clue why the one for amdgpu isn't up to date with the one in the pro package.

Ahh, sorry... I didn't realize that was the question

AFAICS both are used by the radeon driver - for each image it first tries the new format (lower case chip name) and if that fails it falls back to the old format (upper case chip name). I imagine that logic persists to support the scenario where you have a new kernel but everything else including microcode is older.

In the following snippet from radeon/si.c, new_chip_name is lower case while chip_name is upper case:

    snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", new_chip_name);
    err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);
    if (err) {
        snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", chip_name);
        err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);

The amdgpu driver only uses new format (lower case chip name), so for all practical purposes both drivers use the lower case files.

[geearf]

Ahh, sorry... I didn't realize that was the question

AFAICS both are used by the radeon driver - for each image it first tries the new format (lower case chip name) and if that fails it falls back to the old format (upper case chip name). I imagine that logic persists to support the scenario where you have a new kernel but everything else including microcode is older.

In the following snippet from radeon/si.c, new_chip_name is lower case while chip_name is upper case:

 snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", new_chip_name);
err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);
if (err) {
snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", chip_name);
err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);

The amdgpu driver only uses new format (lower case chip name), so for all practical purposes both drivers use the lower case files.

Ooooh I see, then yes breaking radeon would not be good, but then that's a problem :/
Thank you!