In glxtest, EGL gives different results than GLX did
Categories
(Core :: Graphics, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox85 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | wontfix |
firefox88 | --- | wontfix |
firefox89 | --- | wontfix |
firefox90 | --- | fixed |
People
(Reporter: aosmond, Assigned: aosmond)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 obsolete file)
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.
Assignee | ||
Comment 1•4 years ago
|
||
I used mozregression to confirm the bug since I landed a few GL related changes.
Assignee | ||
Comment 2•4 years ago
|
||
-
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.
-
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?
Assignee | ||
Comment 3•4 years ago
|
||
It appears I get r600
from the actual EGL context as expected, but glxtest reported llvmpipe
.
Comment 4•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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
and0x68be
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•4 years ago
|
||
Comment 9•4 years ago
|
||
Set release status flags based on info from the regressing bug 1680512
Updated•4 years ago
|
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Bug 1689207 is a case where we actually really have different behaviour because of a driver bug, affecting hardware with gles < 3.0 support.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Closed the patch for now. Andrew, can you retest this after bug 1689207 landed?
Comment 14•4 years ago
|
||
Robert, what are the user-visible consequences of this bug?
Comment 15•4 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 16•3 years ago
|
||
This finally has been fixed in bug 1714897.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•