Closed Bug 1688873 Opened 4 years ago Closed 3 years ago

In glxtest, EGL gives different results than GLX did

Categories

(Core :: Graphics, defect, P1)

Desktop
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1714897
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.

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?

Flags: needinfo?(aosmond)

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:

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

Flags: needinfo?(aosmond)

Review ping?

Flags: needinfo?(aosmond)

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

Attachment #9199376 - Attachment is obsolete: true

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

Flags: needinfo?(aosmond)

See above

Flags: needinfo?(aosmond)

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

Flags: needinfo?(robert.mader)

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.

Flags: needinfo?(robert.mader)

This finally has been fixed in bug 1714897.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(aosmond)
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: