While you're here, please consider supporting GamingOnLinux on:
Reward Tiers: Patreon. Plain Donations: PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Reward Tiers: Patreon. Plain Donations: PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register
- GitLab takes down Nintendo Switch emulator suyu due to the DMCA
- Horizon Forbidden West Complete Edition out now on Steam - works on Steam Deck
- AMD FSR 3.1 announced with Vulkan support, upscaling quality improvements
- Founder of Baldur's Gate 3 developer blasts publisher greed
- GE-Proton 9-2 released, ULWGL gets renamed to umu (Unified Linux Wine Game Launcher)
- > See more over 30 days here
-
SDL 3 will prefer Wayland Over X11, if certain protocol…
- Linux_Rocks -
Take-Two Interactive buying Gearbox from Embracer, more…
- whizse -
PUNKCAKE Délicieux just added Linux support to a whole…
- Linux_Rocks -
Oh Snap! Canonical now doing manual reviews for new pac…
- Linux_Rocks -
Take-Two Interactive buying Gearbox from Embracer, more…
- Linux_Rocks - > See more comments
Latest Forum Posts
- How to find out if a game is native for sure?
- Myrhan - Weekend Players' Club 3/22/2024
- Pengling - Nintendo-style gaming, without Nintendo!
- Linux_Rocks - I wish there was a truly trustworthy browser company...…
- Kuduzkehpan - GPU recommendations to make a gaming system with some older compo…
- bonkmaykr - See more posts
View PC info
It gets pulled in automatically on Arch, right?
I never did that manually.
View PC info
The ones I had previously
foo@bar:/lib/firmware/amdgpu/bak$ md5sum *
5074bcbcc3592cb22d0a0ef04ead35ab navi10_asd.bin
3f52075a7db731365236d3050aa23d9e navi10_ce.bin
d99c5124e5560153768a71cec8a4726e navi10_gpu_info.bin
98ddcd564bddf7ed6045afff4abf6704 navi10_me.bin
c9cd7f8cdd97c18f3068887f1877e2a6 navi10_mec2.bin
c9cd7f8cdd97c18f3068887f1877e2a6 navi10_mec.bin
2dd1563ba76158c98d9409eb94daab2e navi10_pfp.bin
5261715f1fbcfa6e586012dfa922356c navi10_rlc.bin
5f41f20b8e89dfecb0d9e25cebd661cb navi10_sdma1.bin
5f41f20b8e89dfecb0d9e25cebd661cb navi10_sdma.bin
ca8b8ef19533560979d28fcd100dadce navi10_smc.bin
7f06e5bc7c740c12be2c4c70a877ba2c navi10_sos.bin
d6d91356292b5795a62ff944dea35f45 navi10_vcn.bin
The ones I have now (copied from who knows where)
foo@bar:/lib/firmware/amdgpu$ md5sum navi10*
c906f2da7ad8b89e33f3cd134d734048 navi10_asd.bin
b6ed20f0474ecaeea76d012007d0d649 navi10_ce.bin
d99c5124e5560153768a71cec8a4726e navi10_gpu_info.bin
979f8cb3fa80c39579defdcb5d2e67cf navi10_me.bin
91ebf96e685bfb26df02300e68a38d3c navi10_mec2.bin
91ebf96e685bfb26df02300e68a38d3c navi10_mec.bin
b224f16230c2d9dcf8454c2ff4c91a59 navi10_pfp.bin
8079175c2641084b982a116b46997516 navi10_rlc.bin
94e4e03692743d9d4f1f5493a2c0a3e4 navi10_sdma1.bin
94e4e03692743d9d4f1f5493a2c0a3e4 navi10_sdma.bin
7cb1705435cabe9f4220d9388b52f46c navi10_smc.bin
1d75437a69d7070f174913eeb9b5a8aa navi10_sos.bin
d64f8f5998de0d95cbeb18d5f73a6c0b navi10_ta.bin
1afe1cd7fc5ec5ac02707bf933365e7e navi10_vcn.bin
The ones that come with 20.04:
foo@bar:/lib/firmware/amdgpu$ md5sum navi10*
c906f2da7ad8b89e33f3cd134d734048 navi10_asd.bin
013d6b13e32b251a15f20d116b692a0c navi10_ce.bin
d99c5124e5560153768a71cec8a4726e navi10_gpu_info.bin
273cae45d26d7f9b94b8913ebcca4ee5 navi10_me.bin
99965d301414640b8136be603899fe5e navi10_mec2.bin
99965d301414640b8136be603899fe5e navi10_mec.bin
2b18285f717e0b836646b4622326e4fa navi10_pfp.bin
d59ec47efc4283d3d7df8960f7f68380 navi10_rlc.bin
1d5f14e1061aac5bf4a7cdb267f9619e navi10_sdma1.bin
1d5f14e1061aac5bf4a7cdb267f9619e navi10_sdma.bin
c11beaf3cd5da0704cdf4ecaf781ad2f navi10_smc.bin
1416ca567e33480dc2723d9979b46c17 navi10_sos.bin
5ba13b8604df3627499d8fd1eb6511a5 navi10_ta.bin
1afe1cd7fc5ec5ac02707bf933365e7e navi10_vcn.bin
That's one of the major points of my rant: What is supposed to be the "correct configuration" for an RX 5700? How many firmware versions are floating around? Which one is the firmware to go for? (Which kernel versions, which Mesa versions, etc.)
I've tried again the different kernels on my to-become 20.04 partition:
Kernel 5.4 (if it boots smoothly, which it does half of the time):
foo@bar$ grep -rin amdgpu kernel-5.4-dmesg
...
1262:[ 2.449914] kernel: [drm] amdgpu: 8176M of VRAM memory ready
1263:[ 2.449917] kernel: [drm] amdgpu: 8176M of GTT memory ready.
1308:[ 3.348134] kernel: amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a2f84 (42.47.132)
1309:[ 3.348135] kernel: amdgpu: [powerplay] SMU driver if version not matched
1310:[ 3.362269] kernel: amdgpu: [powerplay] SMU is initialized successfully!
...
1384:[ 3.628322] kernel: [drm] Initialized amdgpu 3.35.0 20150101 for 0000:0c:00.0 on minor 0
Kernel 5.5.4
foo@bar$ grep -rin amdgpu kernel-5.5-dmesg
...
1258:[ 2.464659] [drm] amdgpu: 8176M of VRAM memory ready
1259:[ 2.464665] [drm] amdgpu: 8176M of GTT memory ready.
1293:[ 3.348051] amdgpu: [powerplay] use vbios provided pptable
1294:[ 3.348132] amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a2f84 (42.47.132)
1295:[ 3.348132] amdgpu: [powerplay] SMU driver if version not matched
1298:[ 3.402489] amdgpu: [powerplay] SMU is initialized successfully!
1397:[ 6.272203] [drm] Initialized amdgpu 3.36.0 20150101 for 0000:0c:00.0 on minor 0
...
1421:[ 12.453852] amdgpu: [powerplay] failed send message: SetHardMinByFreq (28) param: 0x0002036b response 0xffffffc2
Kernel 5.6RC2
foo@bar$ grep -rin amdgpu kernel-5.6-dmesg
...
1290:[ 2.513659] [drm] amdgpu: 8176M of VRAM memory ready
1291:[ 2.513661] [drm] amdgpu: 8176M of GTT memory ready.
1319:[ 3.408019] amdgpu 0000:0c:00.0: RAS: ras ta ucode is not available
1320:[ 3.440055] amdgpu: [powerplay] use vbios provided pptable
1321:[ 3.440121] amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a2f84 (42.47.132)
1322:[ 3.440122] amdgpu: [powerplay] SMU driver if version not matched
1323:[ 3.498253] amdgpu: [powerplay] SMU is initialized successfully!
...
1370:[ 3.864297] [drm] Initialized amdgpu 3.36.0 20150101 for 0000:0c:00.0 on minor 0
1414:[ 12.014221] amdgpu: [powerplay] failed send message: SetHardMinByFreq (28) param: 0x0002036b response 0xffffffc2
5.5 and 5.6 still have a single powerplay issue but it doesn't seem to do any harm.
Now to the FPS with ROTR (apart from the kernel everything else is identical):
5.4 - 33fps (maybe some clocking issue since the fan doesn't noticeably spin up)
5.5 - 134fps (hooray! Not up to my 18.04, kernel 5.3 setup which yields 143fps, but close enough, enabling ACO might already do the trick)
5.6rc - 133fpe (again hooray!)
So unless some patches aren't backported to 5.4 I might at least be fine with 5.5+. Remains only the OpenCL tinkering. Hopefully.
View PC info
Nope.
5.3 - ok
5.4 - unusable
5.5 - ok
5.6 - we will see
View PC info
Not in my experience. You clearly didn't upgrade things properly, likely using outdated firmware like TobyGornow suggested above. You don't need to copy it from "who knows where". Use the upstream link above, and keep it always up to date.
View PC info
Look: I didn't upgrade anything. 5.4 is unusable both on an Ubuntu 19.10 and an Ubuntu 20.04 - both are/were OOTB installations. I assume the firmware on 20.04 is ok, because 5.5+ seems to work. Was that clear enough? And the "copied from who knows where" firmware works perfectly ok with my kernel 5.3 which you stated was bad. Which isn't backed by Toby, too.
View PC info
Thanks for that.
View PC info
Timing matters. Kernels don't remain frozen in time. I.e. initial fixes appear in recent kernels, later some of them are backported to older ones (not all). So it's not impossible to first use 5.4.1 or something and have bad experience, and then use 5.3.9 or some such, and have a better one. If you update with delay (which is common for non rolling distros), such stuff can happen.
Last edited by Shmerl on 17 February 2020 at 10:50 am UTC
View PC info
[powerplay] failed send message: NumOfDisplays (64) param: 0x00000002 response 0xffffffc2
several time. While not crashing your machine this will slow down the boot process horribly since between each try there is a 3 seconds delay. Plus - as stated numerous times before - it leaves me wondering which kernel version will (re-)introduce another breakage.
Or is it the BIOS (Mesa didn't receive an update in the meantime)? According to the changelog
linux-firmware (1.187) focal;
...
* Rebase against git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
8eb0b281511d6455ca9151e52f694dc982193251 (LP: #1865130)
...
- amdgpu: update vega10 firmware from 19.50
...
- Seth Forshee <[email protected]> Thu, 19 Mar 2020 11:37:49 -0500
Obviously not. The MD5s of the Navi10-files extracted from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?qt=grep&q=navi10
are exactly the ones currently installed via the official Ubuntu repo.
Well, it was nice as long as it lasted. Meanwhile kernel 5.3 on my 18.04 has to soldier on.
View PC info