32-bit Mesa software renderer crashes. Possibly never worked before

[pal1000]

Quick test. Download PPSSPP (either dev build or stable) and drop mesa dll(s) in the extracted folder. Attempt to run PPSSPP will lead to an instant crash. 64-bit Mesa and PPSSPP work just fine. I tested most versions available on Sourceforge from 10.6.2 to latest 13.0.3. Other programs I was able to replicate with are:

• ePSXe with Pete's OpenGL2 plugin or GPU core plugin (requires either Playstation 1 firmware image or a game to test, best to have both; GPU core plugin was added in ePSXe 2.0; ePSXe 2.0.5 comes with both plugins builtin; OpenGL 2.1 is required by both; Pete's OpenGL2 plugin default render mode "Render to pbuffer texture" is so deprecated that even mesa can't use it, it leads to black screen so don't even bother with it, use "Render to pbuffer copy to texture" or the most modern "framebuffer objects");
• Aida64 engineer (and possibly other flavors). This system utility program doesn't crash right away. After completely loading, select Display then OpenGL from left pane. This will trigger the crash if MSYS2 mesa dlls are dropped along Aida64 executable.
  Issue originally posted on Sourceforge: SF MSYS2 #216.

[pal1000]

QTCreator for Windows includes a 32-bit build of llvmpipe that works as expected but it is really out of date. More direct downloads for various versions are available here. It appears they used Arch Linux to build mesa 10.x according to this, now they switched to Windows exclusive using Visual Studio 2015 and various cross-platform libraries and compilers.

[pal1000]

I was able to build it with Visual Studio 2015 following the tutorial I linked on my previous post and is working as expected, The only caveat is I had to build it with LLVM 3.7.1. Any newer version of LLVM fails to link (known issue), the fix has landed in time for upcoming Mesa 17, though. So the problem is definitely with MSYS2 cross-compiling. The only dependency I took from MSYS2 was m4.

[Alexpux]

Issue maybe in GCC dwarf exceptions.

[pal1000]

Mingw build of Mesa 17.0.0 is still affected.

[mati865]

@pal1000 is the osmesa.pc file used when building PPSSPP? It contains path to 64 bit libs.

I'll try to look into it but cannot promise anything.

[pal1000]

PPSSPP doesn't seam to use osmesa anywhere. I searched for osmesa in the source code both with Windows Explorer (search file contents) and Visual Studio entire solution and both searches returned nothing.
Actually for 64-bit PPSSPP to work I need neither osmesa.dll nor graw.dll. I'll test Desmume Nintendo DS emulator, I am curious how that behaves.

[pal1000]

Tested Desmume and is affected in similar fashion. Desmume works initially (with default 3D settings) because it uses a software rasterier, but as soon as I switch to OpenGL (either old or new) it crashes right away, actually you can't even get the configuration to stick because Desmume attempts to load OpenGL right away. Additionally in the Command Prompt like log console it appears that Desmume doesn't even identify Mesa virtual GPU, says it is unknown. Since it crashes so early you don't even need any Nintendo DS game to replicate.

[mati865]

This can put some light on this issue: https://sourceforge.net/p/mingw-w64/bugs/599/ Adding -fno-omit-frame-pointer or specifying -O1 should get rid of the crashes.

[pal1000]

GCC 4.9 may be affected as well. I tested old GCC 4.9 builds from here: https://sourceforge.net/projects/msys2/files/REPOS/MINGW_GCC_4_9/i686/ The oldest - 10.0.0 is not affected, but the newest 10.6.0 is. What's interestingly different about 10.0.0 is that it was built without LLVM, so it only includes the very slowest softpipe driver. I will do a sort-of bisecting soon.

[pal1000]

The build of Mesa 17.3.3 i686 is working as expected. Finally this long standing issue has been fixed.

[sezero]

It would be good to know precisely what fixed it.

[pal1000]

Migration to GCC 7.2.0 and up. It may share root cause with #2271.

[revelator]

hmm it seems to be back with gcc-11.2.0 32 bit crashes 64 bit works.