Announcement

Collapse
No announcement yet.

Radeon Software 18.20 Stable Released With Official Ubuntu 18.04 LTS Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MasterCATZ
    replied
    anyone else NOT have the Uninstall Script generated, just have to spend 2 hrs manually de-installing each deb file individually in a safe mode terminal

    Leave a comment:


  • jf3110
    replied
    Originally posted by Nitrogen View Post
    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.
    Ryzen 5 2400G was already supported with 18.10 drivers. With both drivers (18.10 and 18.20) the gpu in clinfo lists as "Unknown AMD GPU", but otherwise works nicely. I'm using these drivers only for OpenCL and open source MESA with amdgpu for the rest of the application stack. Be sure to have the RAVEN*.bin firmware files in the kernel. Also: kernels prior to 4.17 have stability issues with amdgpu enabled.

    Leave a comment:


  • geearf
    replied
    Originally posted by bridgman View Post

    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:
    Code:
     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!

    Leave a comment:


  • bridgman
    replied
    Originally posted by geearf View Post
    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:
    Code:
        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.
    Last edited by bridgman; 26 June 2018, 05:52 AM.

    Leave a comment:


  • geearf
    replied
    Originally posted by bridgman View Post

    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.

    Leave a comment:


  • bridgman
    replied
    Originally posted by geearf View Post
    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.
    Last edited by bridgman; 24 June 2018, 06:28 PM.

    Leave a comment:


  • Nitrogen
    replied
    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.

    Leave a comment:


  • geearf
    replied
    Originally posted by bridgman View Post

    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

    Leave a comment:


  • bridgman
    replied
    Originally posted by geearf View Post
    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...

    Leave a comment:


  • geearf
    replied
    Originally posted by bridgman View Post

    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?

    Leave a comment:

Working...
X