1688873 - In glxtest, EGL gives different results than GLX did

Status: RESOLVED DUPLICATE of bug 1714897

(Core :: Graphics, defect, P1)

Description

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

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.

Comment 1

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

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

Comment 2

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

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?

Comment 3

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

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

Comment 4

[Robert Mader [:rmader]]

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.

Comment 5

[Robert Mader [:rmader]]

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?

Comment 6

[Robert Mader [:rmader]]

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."

Comment 7

[Robert Mader [:rmader]]

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

Comment 8

[Robert Mader [:rmader]]

Attachment: Bug 1688873 - Fall back to GLX if we got sw driver on EGL, r=aosmond

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 10

[Julien Cristau [:jcristau]]

Review ping?

Comment 11

[Robert Mader [:rmader]]

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

Comment 12

[Robert Mader [:rmader]]

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

Comment 13

[Robert Mader [:rmader]]

See above

Comment 14

[Julien Cristau [:jcristau]]

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

Comment 15

[Robert Mader [:rmader]]

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.

Comment 16

[Robert Mader [:rmader]]

This finally has been fixed in bug 1714897.