With bug 1680512, detecting via EGL:

GPU #1
Active Yes
Description llvmpipe (LLVM 11.0.0, 256 bits)
Vendor ID 0x1002
Device ID 0x68be
Driver Vendor mesa/llvmpipe
Driver Version 20.2.6.0`

Without/before bug 1680512, detecting via GLX:

GPU #1
Active Yes
Description AMD JUNIPER (DRM 2.50.0 / 5.8.0-38-generic, LLVM 11.0.0)
Vendor ID 0x1002
Device ID 0x68be
Driver Vendor mesa/r600
Driver Version 20.2.6.0

I'm not sure what we are actually using in the parent process with WebRender but since we still default to GLX, it should still be using the proper hardware. It is just the reporting and telemetry that is very wrong.

I used mozregression to confirm the bug since I landed a few GL related changes.

1. Does the glxtest process ever return different results for the same backend (EGL/GLX) as we would in the parent process when we actually use the EGL/GLX context? This could represent a major error in our telemetry collection and about:support that we should correct.

2. Do we need to run both EGL and GLX in glxtest (if possible) to collect separate results for both and evaluate which to use? E.g. accelerated GLX may be a better choice than unaccelerated EGL?

It appears I get r600 from the actual EGL context as expected, but glxtest reported llvmpipe.

This looks like mesa bug to me - probably only in the r600 EGL one. Mesa does report the right driver in other cases AFAIK, I'll have a look into it.

Andrew, do you have the hardware to test this? Could you verify that this particular driver does return the respective results from above in the two glGetString(GL_RENDERER); calls, the one in GLX returning a good result while the EGL one returning llvmpipe?

From #dri-devel: "anholt: you're just loading a software driver. EGL_LOG_LEVEL=debug may help you figure out why, but egl's pretty bad at driver setup debug."

Ok, so I think what happens is:

• something in the EGL setup is bogus, we get a software driver, mDriverVendor get set, mVendorId stays empty
• because of the new pci based detection in https://searchfox.org/mozilla-central/source/widget/GfxInfoX11.cpp#404 we make a smart guess for the correct IDs, thus still report 0x1002 and 0x68be

So I guess if we end up getting a software driver in EGL, we should fall back to also try GLX. Fortunately we already have a easy way to check that using eglQueryDeviceStringEXT: https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#505-508

So it's probably enough to have a else { return false; } at https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#520

Set release status flags based on info from the regressing bug 1680512

Review ping?

Bug 1689207 is a case where we actually really have different behaviour because of a driver bug, affecting hardware with gles < 3.0 support.

Closed the patch for now. Andrew, can you retest this after bug 1689207 landed?

See above

Robert, what are the user-visible consequences of this bug?

Well, this bug is just about, quoting the first post, "the reporting and telemetry that is very wrong."

It's not clear yet if there are any cases where Webrender is silently falling back to software rendering via llvmpipe, and there have been fixes to align glxtest closer to how we create GL contexts in WR. So actually I hope this simply already has been fixed - we'd need to hear back from Andrew though.

This finally has been fixed in bug 1714897.