[Bug 50864] New: Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Bug ID: 50864
           Summary: Incompatibility with Mesa 21 with several games
           Product: Wine
           Version: 6.4
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Arch Linux recently updated mesa to 21, after which I was unable to start most
of the games I play through Steams proton (Through the Ages, Race for the
Galaxy, Galaxy Trucker, ...). Since proton is based on wine I later found a
command line reproducer for the problem by just running "wine game.exe" with
the appropriate wine prefix. After noticing that the issues appeared with Mesa
21 I found this on the Mesa gitlab:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969

My issues are exactly the same. Apparently Mesa added an OpenGL error in this
commit / line:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/f39fd3dce72eaef59ab39a23b7...

And it appears that wine fails to correctly handle / catch that error. I can
play games again after reverting that change in mesa and recompiling mesa 21.
While it was mesa that introduced this regression it appears that it is correct
to issue the error, so the mesa developers seem to think that wine should be
patched instead (they even made an attempt).

Thanks for any help!

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #1 from [e-mail] ---
I forgot to mention the X error which appears on the command line if launching
"wine game.exe" with mesa 21:

X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  0 ()
  Serial number of failed request:  341
  Current serial number in output stream:  341

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Starous  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Starous  ---
Confirmation. I have exactly the same issue on PC with Artix Linux (kernel
5.11.10-artix1-1) with wine 6.4-1 (and the same problem is with wine-staging
6.5-1):
X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  0 ()
  (next two lines have different numbers in my case, but it does not matter,
AFAIK...)

According some googling, maybe the problem is caused not by Mesa itself, but by
older graphics HW - ? (Intel 82Q963/Q965 integrated graphic in my case - I am
using Wine here for non-game & non-video applications, so such GPU is
sufficient for me.)
(OpenGL renderer string: Mesa DRI Intel(R) 965Q (BW); OpenGL version string:
2.1 Mesa 21.0.1)

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #3 from Rafał Mużyło  ---
Likely a dupe of bug 50859 - so change in mesa triggered it, but the card might
be a factor in the function failing in the first place.

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #4 from Starous  ---
I agree.
The same version of Mesa & Wine are working well on my another computer with
newer graphic card.
So, there is probably a bug in Mesa related to some older GPU. Or, in worse
case, Mesa intentionally stopped supporting of some older HW...

My temporary solution is downgrade... :-(

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

LingM  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #5 from LingM  ---
> Or, in worse case, Mesa intentionally stopped supporting of some older HW...

No. There is currently some talk about moving legacy drivers to a dedicated
-lts branch because changes to common code caused regressions for older, less
well tested hardware. However, (a) that hasn't happened yet and the current ETA
is roughly 21.2 and (b) even then support isn't really dropped, although you
might need to install a special mesa version to get drivers that are in pure
maintenance mode.

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

swm  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #6 from [e-mail] ---
I also have this problem.  I use Arch linux, a radeon HD 5850, intel 4300.

a weird thing is that Proton 3.7 worked for me to play BIT.TRIP RUNNER, Command
and Conquer 3: Tiberium Wars, Deus Ex: Human Revolution - Director's Cut, and
Rocksmith 2014 Edition - Remastered.  no newer version of proton worked for
them.

Star Wars: The Old Republic didn't work until proton 5.0, so I've done the mesa
backtrack.

yes, it's proton, but hopefully, it helps.  if anyone wants to test wine 3.7 to
verify that it works? (with mesa 21)  if so, that could be a hint, right?  see
what changed

I tried to get 3.7 from the AUR, but it says:

==> Verifying source file signatures with gpg...
    wine-3.7.tar.xz ... FAILED (unknown public key CEFAC8EAAF17519D)
==> ERROR: One or more PGP signatures could not be verified!

https://aur.archlinux.org/packages/wine37/

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #7 from [e-mail] ---
This bug is triggered by a new error (GLXBadFBConfig) which is emitted in Mesa
21 (maybe only in certain cases, specific HW, supported GL version, ...).

If you read https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969 you will
understand the details. The mesa developer suggested to wrap the call to

pglXCreateContextAttribsARB

in dlls/winex11.drv/opengl.c (create_context function)

in X11DRV_expect_error in order to turn the error into a warning. I think this
is a fine solution. However, X11DRV_expect_error only works if a X server
request is made, which does not happen in this case (see the mesa gitlab
ticket).

In any case I don't think mesa developers will change anything so it should be
fixed here.

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #8 from Henri Verbeet  ---
(In reply to bastian.beischer from comment #7)
> If you read https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969 you will
> understand the details.

Frankly, I don't find the Mesa report all that clear, although part of that may
just be gitlab. In any case, the concrete questions I have are the following:

- Why is GLXBadFBConfig generated in the first place? Is it caused by a
bug/issue in Wine or Mesa, or is it a legitimate error caused by e.g. the
driver not supporting the requested context version?

The patch suggested by Adam Jackson on January 27 (seemingly no comment
numbers in gitlab?) would be fine in principle, but doesn't make a lot of sense
on first sight; when create_glxcontext() is called from
glxdrv_wglCreateContext(), "context->gl3_context" would be FALSE, and
glXCreateContextAttribsARB() would not be used. Similarly, even if we did get
there, I'd expect glXCreateContextAttribsARB() to be called with a NULL
attribute list.

In the case of the backtrace posted by "swm" on April 7 we indeed *don't*
go through glxdrv_wglCreateContext(), and create_glxcontext() gets called from
X11DRV_wglCreateContextAttribsARB() instead. A potential GLXBadFBConfig would
be expected there, but should get handled by the error handler we install.

- Why does the serial of the generated error match a request previous to the
glXCreateContextAttribsARB() call? And why would that not be a Mesa/X11 bug?
> The mesa developer suggested to wrap the call to
>
> pglXCreateContextAttribsARB
>
> in dlls/winex11.drv/opengl.c (create_context function)
>
> in X11DRV_expect_error in order to turn the error into a warning. I think
> this is a fine solution. However, X11DRV_expect_error only works if a X
> server request is made, which does not happen in this case (see the mesa
> gitlab ticket).

Moving the X11DRV_expect_error() call to create_glxcontext() might be fine, but
it's not clear to me that it should be needed. The backtrace by "swm" and your
(you're Bastian Beranek on freedesktop gitlab, right?) comments on April 15 and
16 certainly suggest it isn't.

The serial of the generated error pointing to a previous request seems like a
clear bug, and I suspect that simply fixing that would allow the existing error
handler to work as expected. If I'm overlooking something there please it out;
it's not clear to me from the Mesa report.

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #9 from [e-mail] ---
(In reply to Henri Verbeet from comment #8)
> Frankly, I don't find the Mesa report all that clear, although part of that
> may just be gitlab. In any case, the concrete questions I have are the
> following:

Right - there certainly is a bit of history there. Sorry about that.
> - Why is GLXBadFBConfig generated in the first place? Is it caused by a
>
> bug/issue in Wine or Mesa, or is it a legitimate error caused by e.g. the
> driver not supporting the requested context version?

The mesa developers seem to be of the opinion that it is a legitimate error.
I'm not familiar enough with mesa to have an opinion myself.
> The patch suggested by Adam Jackson on January 27 (seemingly no comment
>
> numbers in gitlab?) would be fine in principle, but doesn't make a lot of
> sense on first sight; when create_glxcontext() is called from
> glxdrv_wglCreateContext(), "context->gl3_context" would be FALSE, and
> glXCreateContextAttribsARB() would not be used. Similarly, even if we did
> get there, I'd expect glXCreateContextAttribsARB() to be called with a NULL
> attribute list.
> In the case of the backtrace posted by "swm" on April 7 we indeed
>
> *don't* go through glxdrv_wglCreateContext(), and create_glxcontext() gets
> called from X11DRV_wglCreateContextAttribsARB() instead. A potential
> GLXBadFBConfig would be expected there, but should get handled by the error
> handler we install.

I think you might be right, I will debug a bit more to confirm your position. I
guess the reason they suggested to move the error handler was that they assumed
none was installed in the critical code path, note that the backtrace provided
by swm was not available at that time.

In reality, at least when going through X11DRV_wglCreateContextAttribsARB(),
the error handler is installed, but doesn't function because the serial number
of the error was not increased.
> - Why does the serial of the generated error match a request previous to
>
> the glXCreateContextAttribsARB() call? And why would that not be a Mesa/X11
> bug?

That's what I tried to ask them as well ("is it wrong for mesa to expect that
the request number was increased"). I guess the situation is that no actual
request was sent to the X server. Instead the error is issued based on analysis
of other data. And I don't know if that is valid. It might not be, purely
because each error should have be associated with a unique serial number. Is
that what you're saying?
> > The mesa developer suggested to wrap the call to
> >
> > pglXCreateContextAttribsARB
> >
> > in dlls/winex11.drv/opengl.c (create_context function)
> >
> > in X11DRV_expect_error in order to turn the error into a warning. I think
> > this is a fine solution. However, X11DRV_expect_error only works if a X
> > server request is made, which does not happen in this case (see the mesa
> > gitlab ticket).
>
> Moving the X11DRV_expect_error() call to create_glxcontext() might be fine,
> but it's not clear to me that it should be needed. The backtrace by "swm"
> and your (you're Bastian Beranek on freedesktop gitlab, right?) comments on
> April 15 and 16 certainly suggest it isn't.

Yes, that's me.
> The serial of the generated error pointing to a previous request seems like
> a clear bug, and I suspect that simply fixing that would allow the existing
> error handler to work as expected. If I'm overlooking something there please
> it out; it's not clear to me from the Mesa report.

I agree, if indeed it is correct to expect a unique serial number for each
error.

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #10 from [e-mail] ---
(In reply to bastian.beischer from comment #9)
> That's what I tried to ask them as well ("is it wrong for mesa to expect
> that the request number was increased").

*wine

[Bug 50864] Incompatibility with Mesa 21 with several games

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #11 from Henri Verbeet  ---
(In reply to bastian.beischer from comment #9)
> (In reply to Henri Verbeet from comment #8)
> > - Why is GLXBadFBConfig generated in the first place? Is it caused by a
> >
> > bug/issue in Wine or Mesa, or is it a legitimate error caused by e.g. the
> > driver not supporting the requested context version?
>
> The mesa developers seem to be of the opinion that it is a legitimate error.
> I'm not familiar enough with mesa to have an opinion myself.

It may very well be, and if we got there through
X11DRV_wglCreateContextAttribsARB(), that's a fair bit more likely. Still, it's
useful to know why things happen.
> > The patch suggested by Adam Jackson on January 27 (seemingly no comment
> >
> > numbers in gitlab?) would be fine in principle, but doesn't make a lot of
> > sense on first sight; when create_glxcontext() is called from
> > glxdrv_wglCreateContext(), "context->gl3_context" would be FALSE, and
> > glXCreateContextAttribsARB() would not be used. Similarly, even if we did
> > get there, I'd expect glXCreateContextAttribsARB() to be called with a NULL
> > attribute list.
> > In the case of the backtrace posted by "swm" on April 7 we indeed
> >
> > *don't* go through glxdrv_wglCreateContext(), and create_glxcontext() gets
> > called from X11DRV_wglCreateContextAttribsARB() instead. A potential
> > GLXBadFBConfig would be expected there, but should get handled by the error
> > handler we install.
>
> I think you might be right, I will debug a bit more to confirm your
> position. I guess the reason they suggested to move the error handler was
> that they assumed none was installed in the critical code path, note that
> the backtrace provided by swm was not available at that time.

Right, it wasn't necessarily a bad thing to try; the "context->gl3_context"
thing is perhaps a little subtle, particularly when you're unable to reproduce
the issue yourself.
> > - Why does the serial of the generated error match a request previous to
> >
> > the glXCreateContextAttribsARB() call? And why would that not be a Mesa/X11
> > bug?
>
> That's what I tried to ask them as well ("is it wrong for mesa to expect
> that the request number was increased"). I guess the situation is that no
> actual request was sent to the X server. Instead the error is issued based
> on analysis of other data. And I don't know if that is valid. It might not
> be, purely because each error should have be associated with a unique serial
> number. Is that what you're saying?

Kind of. What currently seems to happen is that the reported error gets the
serial of a previous, unrelated, request. From Wine's point of view, we don't
particularly care about the exact serial, but if we were to do the following:

s1 = NextRequest(display);
    glXCreateContextAttribsARB(...);
    s2 = NextRequest(display);

the serial of the reported error should be >= s1, and < s2. Specifically
because we don't want errors from unrelated requests to cause the current call
to fail, or alternatively, ignore errors that shouldn't be ignored. We don't
want to sprinkle XSync() calls all over the code either. Inserting an XNoOp()
as you did seems fine in that regard.

For reference:
https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Using_the_D...

[Bug 50864] Multiple applications crash with X error "GLXBadFBConfig" with Mesa 21

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Zebediah Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                URL|                            |https://gitlab.freedesktop.
                   |                            |org/mesa/mesa/-/issues/3969
            Summary|Incompatibility with Mesa   |Multiple applications crash
                   |21 with several games       |with X error
                   |                            |"GLXBadFBConfig" with Mesa
                   |                            |21
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #12 from Zebediah Figura  ---
This was fixed upstream by
https://cgit.freedesktop.org/mesa/mesa/commit/?id=960c86d6787437b643825baa230bc0cd7f9f7540.

[Bug 50864] Multiple applications crash with X error "GLXBadFBConfig" with Mesa 21

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Zebediah Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #13 from Zebediah Figura  ---
(In reply to Zebediah Figura from comment #12)
> This was fixed upstream by
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=960c86d6787437b643825baa230bc0cd7f9f7540.

...which was released as part of Mesa 21.2.0.

[Bug 50864] Multiple applications crash with X error "GLXBadFBConfig" with Mesa 21

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Zebediah Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luca.finizio.mgbx@hotmail.i
                   |                            |t

--- Comment #14 from Zebediah Figura  ---
*** Bug 51700 has been marked as a duplicate of this bug. ***

[Bug 50864] Multiple applications crash with X error "GLXBadFBConfig" with Mesa 21

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

Ulf Zibis  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #15 from Ulf Zibis  ---
On Ubuntu you can workaround with:
sudo add-apt-repository ppa:savoury1/display && sudo apt upgrade

[Bug 50864] Multiple applications crash with X error "GLXBadFBConfig" with Mesa 21

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50864

--- Comment #16 from Alexandre Julliard  ---
*** Bug 51981 has been marked as a duplicate of this bug. ***