Description of problem:
After upgrading to mesa 21 a couple of programs I run through wine stop working. This is on an old macbook air and I don't use dxvk, because it doesn't work for one of the programs. I tried switching it on for mesa 21, just in case, but it didnt help. Downgrading mesa fixes the problem.

Version-Release number of selected component (if applicable):
21.0.0~rc3-2.fc34 (-1 didn't work either).


Actual results:
[bruno@laptop1 ~]$ env WINEPREFIX="/home/bruno/.wine" /usr/bin/wine C:\\windows\\command\\start.exe /Unix /home/bruno/.wine/dosdevices/c:/users/Public/Desktop/Heroes\ of\ Might\ and\ Magic\ 3\ Complete.lnk
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.1 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:exec:SHELL_execute flags ignored: 0x00000100
0024:fixme:exec:SHELL_execute flags ignored: 0x00004100
[bruno@laptop1 ~]$ 00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0.
X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  0 ()
  Serial number of failed request:  289
  Current serial number in output stream:  289

[bruno@laptop1 ~]$ env WINEPREFIX="/home/bruno/.wine" /usr/bin/wine C:\\windows\\command\\start.exe /Unix /home/bruno/.wine/dosdevices/c:/users/Public/Desktop/Sins\ of\ a\ Solar\ Empire®\ -\ Rebellion\ Ultimate\ Edition.lnk
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.1 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:exec:SHELL_execute flags ignored: 0x00000100
0024:fixme:exec:SHELL_execute flags ignored: 0x00004100
[bruno@laptop1 ~]$ 00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0.
00fc:fixme:gameux:GameExplorerImpl_VerifyAccess (058D6B30, L"C:\\GOG Games\\Sins of a Solar Empire - Rebellion\\Sins of a Solar Empire Rebellion.exe", 02EBFC64)
00fc:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (02EBFC2C 1 C) semi-stub
X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  0 ()
  Serial number of failed request:  246
  Current serial number in output stream:  246

P.S. Sorry about the first comment. I accidentally submitted the bug before I was ready by hitting return.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

I tried building rc4 and while I might have gotten something wrong, I'm seeing the same failure. So it is unlikely whatever is causing my problem is fixed in the 21 release.

Thanks for doing an rc4 build. As expected this didn't fix the problem I have. winecfg does run, so it doesn't totally break wine.

Still seeing this with 21.0.0~rc5-2.fc35.

I updated another machine that isn't using intel graphics and it appears to have the same problem

Would it make sense to try to bisect this? It would take me a while to complete it, but probably in less than a month.

With me here too , on a fresh install of Fedora-KDE-Live-34-20210225-n-1 iso mesa version 21.0.0~rc5-2.fc35.

[stefan@fedora ~]$ wine Gw2Setup-64.exe
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.2 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0060:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0060:err:ole:start_rpcss Failed to start RpcSs service
00d0:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00d8:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00d0:fixme:heap:RtlSetHeapInformation 0000000000010000 0 000000000021FD60 4 stub
00d0:fixme:heap:RtlSetHeapInformation 0000000001720000 0 000000000021FD40 4 stub
00d0:fixme:heap:RtlSetHeapInformation 0000000001720000 1 0000000000000000 0 stub
00dc:fixme:ver:GetCurrentPackageId (0000000001FDFE10 0000000000000000): stub
00e0:fixme:ver:GetCurrentPackageId (00000000020EFE10 0000000000000000): stub
00e4:fixme:ver:GetCurrentPackageId (00000000021FFE10 0000000000000000): stub
00d0:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  0 ()
  Serial number of failed request:  225
  Current serial number in output stream:  225

I'll start a bisect using scratch builds to build the i686 and x86_64 parts together. It looks like I need to search between 20.3.2 and 21 rc3. I don't know how well mesa builds work when they are cut at arbitrary commits, but I'll give it a try. I can probably average 2 or 3 tests a day.

Turns out bisecting this at the package level is hard because the build system change some stuff between 20 and 21.
The good news is that it looks like this issue is probably already being tracked upstream. Some people have tested reverting a mesa commit with success, though it looks like the root cause is really in wine. People did not seem to have success using a suggested patch to wine.
The issue is: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969
I'm going to try doing a scratch build this weekend with f39fd3dc reverted and see if that works for me.

That is already a positive statement:)
Is there actually to these errors of Wine Project any statements?

I don't know anything more about what's happening on the wine side.
A change in rawhide has broken mesa's builds, so I can't easily test building with the reverted commit.
Right now I think the change is really just a warning about a deprecated use that is being escalated to an error to make sure such things are noticed. I tried some things to work around that, but so far I haven't gotten a build to work.

mesa 21 does not appear to fix this. But it looks like it should build again in rawhide, so I'm going to see if I can successfully get it to build with f39fd3dc reverted.

A scratch rebuild of of plain 21 failed, but there was a successful build earlier today. So I need to see if I can figure out what is different between that build and my test build.

I'm not sure if these failures are random or if someone is adding something to make their builds work. adamwill had a recent build fail in rawhide, pvwalter had a success. It could also be churn in rawhide left open a window that worked briefly that is now closed. Anyway, it is very hard for me to test potential work arounds in the current environment.

With a recent fix to mesa to work with llvm 12 I am now able to do scratch builds successfully. I tested a version with f39fd3dce72eaef59ab39a23b75030ef9efc2a40 reverted and it did solve the problem I had with mesa 21. Sins of a solar empire - rebellion and heroes of might and magic III both run now. I still need to run without wine-dxvk on the machine I test this on, because of a separate issue that affects sins of a solar empire - rebellion on i915.
If you want to try this the scratch build is:
https://koji.fedoraproject.org/koji/taskinfo?taskID=64471198

In Fedora 34 Beta with 

mesa-dri-drivers.x86_64_21.0.0-2.fc34 

and wine.x86_64 _6.3-1.fc34 

the error is still present and in winehq-devel.x86_64_6.4-1.1 also still ! this just as info

How can I test your packages ,what command to install ? dnf ?

I tested out 21.0.1 as well and it still has the problem. I did the same build technique and built a scratch build with f39fd3dce72eaef59ab39a23b75030ef9efc2a40 reverted and it worked. I'm not sure we need more testing as we know what the issue is. I think they are waiting for a fix to go into wine and not much seems to be happening there. I think if you just want something working perhaps just use 20.3.5. I expect the f33 version of the package will work and you can get it from https://koji.fedoraproject.org/koji/buildinfo?buildID=1727633 . If you really want mesa 21 right now, then you can get my test build from https://koji.fedoraproject.org/koji/taskinfo?taskID=64553144 . You need to go into the arch specific link. For x86_64 you need both the x86_64 rpms and the i686 rpms. you can supply those to a dnf update command once you have downloaded them. So far I haven't noticed any big difference between 20 and 21. Scratch builds stick around for something like a couple of weeks, so if you use it hang on to a copy of the rpms locally.
I think helping getting things moving on the wine side might be a better way to move this forward. Unfortunately Ajax's patch from the mesa ticket didn't work for the people that tested it. But I don't think there is a wine ticket addressing this issue yet. Even without a proposed fix just opening a wine ticket referencing the mesa bug might help. I don't know enough to have much chance of fixing Ajax's patch up, but maybe it will be easy for the wine guys and they just need to be made aware of the issue.

Thanks first,
the bug was already reported today

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

they could also write something about it at wine.

Thanks for reporting that. Adding a direct reference to the mesa bug might help and mentioning it had a proposed patch from Ajax that didn't work, but that might be starting point might help them find that information sooner.

I have referenced Wine here at https://bugzilla.redhat.com/show_bug.cgi?id=1924933 again

This problem is still occurring with mesa 21.0.2-1.fc35.

Unsurprisingly, the problem persists in 21.0.3-1.fc35.

In https://gitlab.freedesktop.org/mesa/mesa/-/issues/3969 there is a suggested patch to add XNoOp(dpy); which I have tried out. This appears to fix the problem without having to patch wine.

should be fixed bruno 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/960c86d6787437b643825baa230bc0cd7f9f7540

Thanks. As noted above I tested that fix in a scratch build and it worked for me. Once there is a production build with the fix I'll report back on how that works for me.

This is fixed with mesa-21.1.0-1.fc35.