You are not logged in.
I'm using a clean installation of latest Arch, X, XFCE and Firefox, 13600K CPU and Radeon RX-6600
Firefox about:support shows hardware acceleration disabled (Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED)
Following wiki instructions and enabling config settings media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled seems to have fixed the lack of acceleration issue but a new problem arises after enabled those two settings.
The .xsession-errors log is now filled with repeated error messages "Failed to create /home/username/.cache/mesa_shader_cache for shader cache (Permission denied)---disabling"
BTW, vainfo shows everything OK
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 24.2.5-arch1.1 for AMD Radeon RX 6600 (radeonsi, navi23, LLVM 18.1.8, DRM 3.59, 6.11.5-arch1-1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProcReverting media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled back to disabled fix these errors but disables GPU acceleration.
Any idea?
Last edited by athan (2024-10-30 13:48:28)
Offline
Please post the outputs of
$ stat ~/.cache/
$ stat ~/.cache/mesa_shader_cache/Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks for your willingness to help.
Permissions look OK to me...
File: /home/athan/.cache/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 8,18 Inode: 5242899 Links: 25
Access: (0755/drwxr-xr-x) Uid: ( 1000/ athan) Gid: ( 1000/ athan)
Access: 2023-12-04 06:27:14.852748388 +0200
Modify: 2024-10-30 11:36:03.137431093 +0200
Change: 2024-10-30 11:36:03.137431093 +0200
Birth: 2023-12-04 04:57:26.139999758 +0200
File: /home/athan/.cache/mesa_shader_cache/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 8,18 Inode: 5243095 Links: 2
Access: (0700/drwx------) Uid: ( 1000/ athan) Gid: ( 1000/ athan)
Access: 2024-10-30 11:36:03.137431093 +0200
Modify: 2024-10-30 11:36:03.137431093 +0200
Change: 2024-10-30 11:56:03.596195801 +0200
Birth: 2024-10-30 11:36:03.137431093 +0200Last edited by athan (2024-10-31 14:03:23)
Offline
~/.cache permissions are silghtly different for me (no xr -x ) , but mesa_shader_cache is same.
After changing those 2 settings through about:config I get a similar message.
Failed to create /home for shader cache (Permission denied)---disabling.I'm not convinced this is a permission error, it kinda looks like firefox may be using a wrong path.
What is the exact message you get in the x error log ?
Are you using firefox from repos and what version (post pacman -Qi firefox output if unsure) ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The exact message I'm getting is
Failed to create /home/athan/.cache/mesa_shader_cache for shader cache (Permission denied)---disablingActually .xsession-errors is filled with repeated copies of that message.
Are you using firefox from repos and what version (post pacman -Qi firefox output if unsure) ?
Yes, everything including Firefox is from repos (core & extra).
PS: I could of course not use those two settings but then the about:support says that hardware video acceleration is not used.
Last edited by athan (2024-10-31 17:25:18)
Offline
Please check the following topic (use a translator). It's exactly the same issue. A Firefox bug maybe...
https://bbs.archlinuxcn.org/viewtopic.php?id=14578
Last edited by athan (2024-10-31 19:20:42)
Offline
-
Last edited by athan (2024-10-31 19:39:00)
Offline
That thread is indeed about the same issue. It does seem to be related to the sandbox / seccomp , but no real solution was found.
Last 2 posts of the thread :
One suspicious thing I've found so far is that it's related to the VA-API, after I set media.ffmpeg.vaapi.enabled to false in about:config, no matter how much I play the video again, I don't get this error message.
I can't find the exact cause of this error, so I'm going to block it for now by using systemd-run --user -p StandardOutput=null -p StandardError=null firefox.
That seems to ignore the errors and is at best a workaround .
I'll continue to use firefox without HW video-acceleration and play videos that need it outside of the browser.
(Which is my preferred method to watch them anyway)
Can you try with a fresh linux user with minimal configuration ?
This would help to confirm whether the issue is systemwide or user-specific .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Can you try with a fresh linux user with minimal configuration ?
This would help to confirm whether the issue is systemwide or user-specific .
I did that; no difference unfortunately.
Enabling HW acceleration brings back the error.
Offline
Does HW acceleration function ( lower cpu usage - increased gpu during playing, less stutter etc) despite of the error ?
Can you try with older firefox versions ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
It doesn't seem to make any difference with non-accelerated or it's too small to be noticed.
It's the about:support screen that shows HW acceleration disabled when the above settings are not used.
May I ask you, are you using those two settings?
And if not, does your about:support shows acceleration disabled (blocked)?
Offline
I don't
HARDWARE_VIDEO_DECODING
default available
runtime unavailable Force disabled by gfxInfo Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILEDI leave media.ffmpeg.vaapi.enabled and media.hardware-video-decoding.force-enabled at their default values, so false .
My processor has 12 cores and 24 threads, and I setup heavy processes like compiling to not touch 6 threads .
This leaves enough room for software decoding .
For movie playing I mostly use vlc which is also set to sw decoding and rarely misses frames at 2560 x 1440 resolution .
VA-API used to be hit and miss on amd cards with the misses resulting in worse performance then with sw decoding .
I haven't tested if that has improved in the last 4 years.
It probably helps that my primary nvme drive is small (just 250 GiB) but was one of the fastest available in 2018 Q4 when I purchased this system.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
It looks like you're probably right to have them disabled and I'm thinking of adopting this practice myself, at least for now.
However, I have to admit that I expected an opensource application like Firefox to behave more harmoniously on linux than on Windows or MacOS but that's probably not the case...
Thanks for the help, I appreciate that!
Offline
I am the one who posted on bbs.archlinuxcn.org, I have filed the bug on firefox bugzilla, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1921742.
Offline
I am the one who posted on bbs.archlinuxcn.org, I have filed the bug on firefox bugzilla, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1921742.
That's great, hopefully there will be a fix soon. Thanks for the notice!
Offline