I think you should give up on this. I think by talking about "sandbox" in an abstract for what is going on, it fails to describe the what is going on. "sandbox" is an extremely unspecific words and everyone brings in their weird understanding.
- the program (firefox) has extremely poor "privsep" bolted on after the fact, and uses the wrong resources in the wrong processes - the library, is even worse. It believes it can do everything. If this was going to ever work fixed, it would require significant changes in the library. It is designed to operate in a "can do everything" model, and is incompatible with desired constraints. Landry Breuil <lan...@openbsd.org> wrote: > 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 >
