dunno if its the same bug as bug #1505533, but on OpenBSD with our per-process sandboxing, processes have a distinct/different view of the filesystem, the gpu process has been allowed to access /dev/drm0 and usr/lib for swrast via libllvm, so https://get.webgl.org works fine and basic webgl tests are okay.

but about:support shows broken webgl info, and on stderr i have this:

libGL error: failed to open /dev/drm0: No such file or directory
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/X11R6/lib/modules/dri)
libGL error: failed to load driver: swrast

it seems about:support runs in the main process, and doesnt 'proxy' this information gathering to the gpu process.

adding the missing unveils for /dev/drm0 & /usr/lib helps about:support webgl1 & webgl2 section to show the proper debugging info, but imo this shouldnt be needed, and confuses the end user who might not understand why webgl works/doesnt work.

Parent should not have gpu access sandboxed away. I would not have expected bsd to use a gpu process? Are you sure that content tabs are using out-of-process webgl instead of in-process?

(In reply to Kelsey Gilbert [:jgilbert] (previously Jeff) from comment #1)

Parent should not have gpu access sandboxed away. I would not have expected bsd to use a gpu process? Are you sure that content tabs are using out-of-process webgl instead of in-process?

right, in about:support we have IsWebglOutOfProcessEnabled: 0 so i guess that means 'no' right now, but i was pretty sure that at some point there was a dedicated gpu process (since it was sandboxed/pledged in bug #1580268), but maybe with fission/webrender that changed ?

or that dedicated process is only spawned at startup to gather glx info/environment, and not used anymore for rendering at runtime ? Or some about:config knob (layers.gpu-process.force-enabled or MOZ_ACCELERATED=1 ?) needs to be forced on for the process to be used ?