In order to get Firefox/Wayland, MOZ_ENABLE_WAYLAND must be explicitly set. As such, we should ship WebRender to Wayland users to release in all configurations we support on X11. It is currently already enabled for them on nightly and early beta.

Wayland users are explicitly opting in to use it via MOZ_ENABLE_WAYLAND.
We should give them WebRender if we would otherwise given it on X11.

Fully agree that we should do this. Small reminder that we should try to look into 1655282 over the next two weeks - I have a theory what makes WR on Wayland occasionally crash, compared to basic, see bug 1655282 comment 10

Wayland is used by default on Fedora only, I can fix that with a downstream patch if any issue pops up.

https://hg.mozilla.org/mozilla-central/rev/f2e2b0e933b5

Andrew, I see that WebRender is disabled by default when I have more that one monitor (GPU?). Is that intentional?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Andrew, I see that WebRender is disabled by default when I have more that one monitor (GPU?). Is that intentional?

More than one GPU could be a case that we don't handle well yet. I tried to improve the situation in bug 1717857 - do you see the issue in nightly or stable?

With bug 1717857 is works as expected - GPU from GL is used (I'm testing on system with two discrete AMD GPU).

To be clear here - WebRender HW is disabled by default on 2 GPU system but when I enable it at about:config it works as expected.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #9)

To be clear here - WebRender HW is disabled by default on 2 GPU system but when I enable it at about:config it works as expected.

Hm, if that's the case on nightly, then there's still something wrong. Can you post your about:support?

Comment on attachment 9229548 [details]
about:support

This is clear profile with latest nightly.

Thanks. One more thing: do these GPUs have different device IDs? Because then we should already handle the case. If not, then I have an idea how we can improve the situation.

Device ID: Radeon RX 570 Series (POLARIS10, DRM 3.40.0, 5.12.11-300.fc34.x86_64, LLVM 12.0.0)

Why is this not a proper PCI device ID the whitelist could work with? Shouldn't it be 0x67df [1] [2]?

No, they have the same Vendor ID (0x1002) only:

21:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev ef)
49:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)

When I enable WebRender at about:config a correct GPU is used (the same as GL uses).

(In reply to Darkspirit from comment #14)

Why is this not a proper PCI device ID the whitelist could work with? Shouldn't it be 0x67df [1] [2]?

Because on EGL we still miss a reliable method to get the ID [0] :/ On GLX there is a mesa specific extension that allows us to get it. As we try to move to EGL in glxtest, we now have some guessing logic to get the right ID - but in this case it fails.

Thus the warning:

(#0) Error: More than 1 GPU from same vendor detected via PCI, cannot deduce device

I took deviceString from eglQueryDeviceStringEXT and asked for device_id and vendor_id by using drmGetDevice:
Could that work for the whitelist?
I'm not a programmer, this is wildly copied together:

// sudo apt install libdrm-dev libegl-dev
// clang test.c $(pkg-config --cflags --libs libdrm egl gl) -o test && ./test
#include <fcntl.h>
#include <xf86drm.h>
#include <stdio.h>
#include <EGL/egl.h>
#include <EGL/eglext.h>
int main(int argc, char *argv[]) {
    EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    eglInitialize(display, NULL, NULL);
    //EGLConfig config;
    //EGLint num_config;
    //eglChooseConfig(display, NULL, &config, 1, &num_config);
    //eglBindAPI(EGL_OPENGL_API);
    //EGLContext context = eglCreateContext(display, config, EGL_NO_CONTEXT, NULL);
    //eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, context);
    PFNEGLQUERYDISPLAYATTRIBEXTPROC eglQueryDisplayAttribEXT = (PFNEGLQUERYDISPLAYATTRIBEXTPROC)eglGetProcAddress("eglQueryDisplayAttribEXT");
    PFNEGLQUERYDEVICESTRINGEXTPROC eglQueryDeviceStringEXT = (PFNEGLQUERYDEVICESTRINGEXTPROC)eglGetProcAddress("eglQueryDeviceStringEXT");
    const char* deviceString;
    EGLDeviceEXT device;
    if (eglQueryDisplayAttribEXT(display, EGL_DEVICE_EXT, (EGLAttrib*)&device) == EGL_TRUE) {
        deviceString = eglQueryDeviceStringEXT(device, EGL_DRM_DEVICE_FILE_EXT);
    }
    if (!deviceString) return 0;
    printf("device:%s\n", deviceString);
    int fd = open(deviceString, O_RDONLY);
    if (fd == -1) return 0;
    drmDevicePtr dev;
    if (!drmGetDevice(fd, &dev)) {
        printf("Vendor ID:%#x\nDevice ID:%#x\n",
        dev->deviceinfo.pci->vendor_id,
        dev->deviceinfo.pci->device_id);
    }
    return 0;
}
// output:
// device:/dev/dri/card0
// Vendor ID:0x8086
// Device ID:0x162b

(In reply to Darkspirit from comment #17)

I took deviceString from eglQueryDeviceStringEXT and asked for device_id and vendor_id by using drmGetDevice:
Could that work for the whitelist?
I'm not a programmer, this is wildly copied together:

Ouch, can it really be that easy? Thanks, will take a look!

https://gitlab.freedesktop.org/mesa/drm/-/blob/ab72fde87e6d42aebd1b959e1b81d4fd4cdde1a5/xf86drm.h#L852-858
https://gitlab.freedesktop.org/mesa/drm/-/blob/ab72fde87e6d42aebd1b959e1b81d4fd4cdde1a5/xf86drm.h#L901

comment 17 seems to work on Wayland/Intel and X11/Intel, but not on X11/nvidia-driver-465/Ubuntu 20.10:
EGL/X11 and EGL_EXT_device_query are supported after installing libnvidia-egl-wayland1, device path is returned (/dev/dri/card1), but fd is -1. nvidia-drm.modeset=1 in grub did not help.

Nvidia also added support for USB graphics cards and other devices, that's why the union deviceinfo also has uninteresting non-pci variants:
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-DRM-KMS-USB-Detect
https://cgit.freedesktop.org/mesa/drm/commit/?id=f8484ccbd12ba33ea5b3895efb7a39d986271be0

Thanks Jan! With that info it was actually trivial to add the required bits - it actually was almost there. See 1720187