Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pal1000 opened this issue Jan 16, 2017 · 12 comments

Comments

Projects
None yet
4 participants
@pal1000
Copy link
Contributor

commented Jan 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 6, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 6, 2017

Issue maybe in GCC dwarf exceptions.

@pal1000

This comment has been minimized.

Copy link
Contributor Author

commented Mar 3, 2017

Mingw build of Mesa 17.0.0 is still affected.

@mati865

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 4, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 4, 2017

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 comment has been minimized.

Copy link
Contributor

commented Apr 7, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 30, 2018

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

@pal1000 pal1000 closed this Jan 30, 2018

@sezero

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

It would be good to know precisely what fixed it.

@pal1000

This comment has been minimized.

Copy link
Contributor Author

commented Jan 30, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.