[Bug 50864] New: Incompatibility with Mesa 21 with several games
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: wine-bugs(a)winehq.org Reporter: bastian.beischer(a)rwth-aachen.de 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! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #1 from bastian.beischer(a)rwth-aachen.de --- 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 Starous <starous(a)volny.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |starous(a)volny.cz --- Comment #2 from Starous <starous(a)volny.cz> --- 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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #3 from Rafał Mużyło <galtgendo(a)o2.pl> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #4 from Starous <starous(a)volny.cz> --- 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... :-( -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 LingM <lingm+winebz(a)posteo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lingm+winebz(a)posteo.org --- Comment #5 from LingM <lingm+winebz(a)posteo.org> ---
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.
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 swm <swm+wine(a)not-a.website> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |swm+wine(a)not-a.website -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 stevemario(a)protonmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stevemario(a)protonmail.com --- Comment #6 from stevemario(a)protonmail.com --- 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/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #7 from bastian.beischer(a)rwth-aachen.de --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #8 from Henri Verbeet <hverbeet(a)gmail.com> --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #9 from bastian.beischer(a)rwth-aachen.de --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #10 from bastian.beischer(a)rwth-aachen.de --- (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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #11 from Henri Verbeet <hverbeet(a)gmail.com> --- (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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com 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 <z.figura12(a)gmail.com> --- This was fixed upstream by <https://cgit.freedesktop.org/mesa/mesa/commit/?id=960c86d6787437b643825baa230bc0cd7f9f7540>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #13 from Zebediah Figura <z.figura12(a)gmail.com> --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luca.finizio.mgbx(a)hotmail.i | |t --- Comment #14 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 51700 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 Ulf Zibis <Ulf.Zibis(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Ulf.Zibis(a)gmx.de --- Comment #15 from Ulf Zibis <Ulf.Zibis(a)gmx.de> --- On Ubuntu you can workaround with: sudo add-apt-repository ppa:savoury1/display && sudo apt upgrade -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50864 --- Comment #16 from Alexandre Julliard <julliard(a)winehq.org> --- *** Bug 51981 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla