1776713 - avoid looking for libpci on OpenBSD to improve gfx detection

Status: NEW

(Core :: Graphics, enhancement)

Description

[Landry Breuil (:gaston)]

Attachment: (amdgpu/ryzen) about:support on 102.0rc2 with libpci check printing a warning

related to bug #1676883, on OpenBSD at startup with 102.0 (and the previous versions since bug #1676883) there's an annoying printf to stderr:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=0.795265) [GFX1-]: glxtest: libpci missing

there's no such thing as libpci on OpenBSD.

as a result we end up with webrender as software (cf first attached file for about:support dump)

disabling the check on OpenBSD like this in toolkit/xre/glxtest.cpp:

 static int get_pci_status() {
+#ifdef __OpenBSD__
+  return 1;
+#endif
   void* libpci = dlopen("libpci.so.3", RTLD_LAZY);

allows more webrender features to be enabled afaict on nightly (some of them might be enabled only on nightly and not on release ofc), and at least silences the very annoying message on stderr.

Comment 1

[Landry Breuil (:gaston)]

Attachment: (amdgpu/ryzen) about:support on nightly with the libpci check disabled

Comment 2

[Landry Breuil (:gaston)]

looking at the differences between the two json files, on my amdgpu ryzen 7, that allows/changes the following features:

• HW_COMPOSITING
• OPENGL_COMPOSITING
• WEBRENDER
• WEBRENDER_QUALIFIED
• WEBRENDER_COMPOSITOR goes from blocked on release ("Cannot be enabled in release or beta") to blocklisted (?)
• WEBRENDER_SHADER_CACHE goes from unavailable to disabled
• WEBRENDER_OPTIMIZED_SHADERS goes from unavailable to available
• WEBGPU goes from blocked on release ("Cannot be enabled in release or beta") to disabled

"compositing" goes from "webrender(software)" to "webrender" - via hardware then i guess, since the "AMD Radeon Vega 10 Graphics" renderer is listed instead of llvmpipe.

from all those, i dunno which one make sense/are safe to be enabled - we have mesa 21.3.8 those days.

i'll try the same experiment of disabling the libpci check on 102 to figure out if things are stable/usable.

Comment 3

[Landry Breuil (:gaston)]

from testing a bit with 102.0, the decision log seems similar to what i'd get from forcing MOZ_ACCELERATED=1 MOZ_WEBRENDER=1 in the environment, where HW_COMPOSITING, OPENGL_COMPOSITING are "available" and WEBRENDER is "force_enable". If those mean something...

Comment 4

[Landry Breuil (:gaston)]

i still have some warnings/errors on stderr when going to about:support:

ATTENTION: default value of option mesa_glthread overridden by environment.

afaict that one comes from bug #1670545 - dunno if it also applies to us on OpenBSD.

and

libEGL warning: MESA-LOADER: failed to retrieve device information

that one comes from https://github.com/openbsd/xenocara/blob/master/lib/mesa/src/loader/loader.c#L392 and doesnt seem to trigger anymore when i force webrender/disable detection of libpci.

Comment 5

[Landry Breuil (:gaston)]

bug #1680946 also had some notes about gfx detection.

Comment 6

[Landry Breuil (:gaston)]

Attachment: (intel hd graphics) about:support on 102.0rc2 with libpci check neuteured

on an intel laptop, with the libpci check neuteured on 102.0rc2 i have compositing/webrender available.

Comment 7

[Landry Breuil (:gaston)]

on the same intel laptop with 102.0rc1 (and the libpci check happening) i get the exact same gfx decision log/features, but with the annoying warning message on stderr.

so from my understanding/experience, disabling the libpci check:

• doesn't seem to cause regression on intel hardware (tested on an large amount of hardware: one laptop :)
• allows webrender to go through hardware instead of software on amdgpu (tested on the same amount of hardware)

Comment 8

[Landry Breuil (:gaston)]

i'm puzzled now because on ryzen with 102.0 i only get Webrender (software) (while i was pretty sure i had it working yesterday, but maybe too many different tests...) so rendering via hardware is only possible in nightly ?

edit: in have Webrender with 103.0b1 on the ryzen laptop using an empty profile with all defaults.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

I wonder if we could do something similar on the various BSDs:
https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/pciconf/pciconf.c
https://github.com/openbsd/src/blob/master/usr.sbin/pcidump/pcidump.c
https://github.com/NetBSD/src/blob/trunk/usr.sbin/pcictl/pcictl.c

Comment 10

[Landry Breuil (:gaston)]

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)

I wonder if we could do something similar on the various BSDs:
https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/pciconf/pciconf.c
https://github.com/openbsd/src/blob/master/usr.sbin/pcidump/pcidump.c
https://github.com/NetBSD/src/blob/trunk/usr.sbin/pcictl/pcictl.c

not a good idea imo, because for OpenBSD pcidump requires root access. And i'll have a hard time convicing anyone that a browser should have access to pci internals, even readonly... There's no wayland for now either, so plain old glx detection should be used (and used to work so far)

Comment 11

[Robert Mader [:rmader]]

(In reply to Landry Breuil (:gaston) from comment #10)

...so plain old glx detection should be used (and used to work so far)

Yeah, getting the EGL equivalent into place would be most optimal, such as https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976