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

  • #21
    Originally posted by bridgman View Post

    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.
    geearf
    Senior Member
    Last edited by geearf; 23 June 2018, 06:29 PM.

    Comment


    • #22
      Originally posted by geearf View Post
      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.
      Test signature

      Comment


      • #23
        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?

        Comment


        • #24
          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...
          Test signature

          Comment


          • #25
            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

            Comment


            • #26
              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.

              Comment


              • #27
                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.
                bridgman
                AMD Linux
                Last edited by bridgman; 24 June 2018, 06:28 PM.
                Test signature

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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.
                    bridgman
                    AMD Linux
                    Last edited by bridgman; 26 June 2018, 05:52 AM.
                    Test signature

                    Comment


                    • #30
                      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!

                      Comment

                      Working...
                      X