Le Wed, Aug 14, 2024 at 10:57:46AM +0200, Jan Stary a écrit : > > Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in > > 2160p60 on FF without blowing the CPU? > > On this AMD machine (dmesg and vainfo below), > firefox-129.0 plays this video eating about 14% of CPU. > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND > 23106 hans 2 0 362M 414M sleep/0 kqread 1:14 14.16% firefox > 77528 hans 2 0 427M 467M sleep/3 kqread 1:32 11.38% firefox > 60891 hans 2 0 97M 98M idle kqread 0:20 3.27% firefox > > That's with "media.ffmpeg.vaapi.enabled true" in about:config; > and about the same with "media.ffmpeg.vaapi.enabled false", > which confuses me. > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND > 77528 hans 2 0 429M 470M sleep/5 kqread 1:44 14.06% firefox > 23106 hans 2 0 379M 429M sleep/4 kqread 1:25 12.94% firefox > 60891 hans 2 0 97M 98M sleep/3 kqread 0:26 4.69% firefox > > Is there a better metric of how much firefox video playing > is helped (or not) by vaapi? How can I even tell FF is using it?
whatever knob you frob, firefox is not using vaapi, because vaapi is *not* compatible as-is with the current sandboxing config. there are wip patches in the vaapi branch of my git repo (which is on top of the beta branch), cf https://cgit.rhaalovely.net/mozilla-firefox/?h=vaapi but right now it doesnt work because: - it tries dlopening libs with fixed .so.X version we dont have (easy to fix) - it tries opening the drm device read-write after sandboxing (harder to fix) - the xenocara/mesa gl stack itself also tries to open the drm device rw when creating some gl context at some point so things to explore: - pushing sandbox initialization 'later' once every needed fd is opened/saved somewhere - add the required paths/pledge class for the various syscalls used when decoding (eg during process main loop) if you dont care about sandboxing, ofc you can disable it, but then you're on your own. and that wont work anyway because of the .so.X paths, but ppl like to workaround that by doing symlinks, which is no the correct 'fix' either. check https://bugzilla.mozilla.org/show_bug.cgi?id=1911635 for the details of the various things i've tried so far. to know the status of vaapi at runtime, try with env MOZ_LOG="FFmpegVideo:5,Dmabuf:5,OpenBSDSandbox:5" MOZ_GFX_DEBUG=1 firefox and of course a separate profile. Landry
