#216 The 32-bit build of Mesa 3D software rasterizer crashes

[pal100 rep0roc]

You can test it with PPSSPP. It requires OpenGL 2.0. I tested 64-bit PPSSPP with 64-bit Mesa software rasterizer and has decent performance, but what I need is Mesa 32-bit for Windows.

Background story (stop reading if not interested)

The issue is that Intel pretty much left in the dust people with Sandy Bridge processors and no dGPU on their system since Windows 10 release. Some people experienced complete black screen while most others only experience lack of OpenGL and QSV support. These features are still exposed to applications that misdetect Windows 10 as Windows 8.
Disscussion topics regarding this issue:
-Intel community;
-Reddit;
-Microsoft support.

Objective: Get D3D support on Virtualbox (Sandy Bridge on Windows 10 without dGPU).
Considering that Virtualbox uses host OpenGL for both guest OS OpenGL and D3D, the later being achieved via WineD3D, the options to achieve D3D functionality on guest when there is no host OpenGL functionality are:
-D3D software renderer (ex: SwiftShader);
-OpenGL software renderer (ex: Mesa 3D for Windows)+Wine D3D.

[pal100 rep0roc]

I tested and experienced the crash on a Virtualbox VM 
running Windows XP and one running Windows 10 both 
32-bit. Also tested on Windows 10 64-bit real hardware 
with PPSSPP and Mesa 32-bit with same crash as 
result. Mesa and PPSSPP 64-bit works with OpenGL 3.0 
support according to PPSSPP internal system information 
data.
The Windows XP VM also showed a crash in Bitdefender 
Free Edition GUI and SopCast didn't work at all. 
It's like OpenGL support is nonexistent or very broken 
in 32-bit.

[zeromus]

This is cramping my style too. I get a crash in glCompileShader for a trivial fragment shader that samples a texture. I can get it to work with one that's even more trivial just outputting a color. I'm going to try this at some point : https://wiki.qt.io/Cross_compiling_Mesa_for_Windows

[pal100 rep0roc]

@zeromus, if you need pre-built mesa 3d software rasterizer binaries here you can find them:
-64-bit: http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (v11.0.5. I don't know what is going on but MSYS2 remains behind with a lot of packages lately. 7-Zip can extract that tarball.);
-32-bit: https://download.qt.io/online/qtsdkrepository/windows_x86/desktop/tools_qtcreator/qt.tools.qtcreator/ (mesa 11.0.7 or 11.1.0, don't know exactly, it was compiled on same day as Mesa 11.1.0 release. It is included in QTCreator).

[pal100 rep0roc]

Mesa 11.1.2 with LLVM 3.8 continues to be affected by this issue. I wonder if it will ever be fixed.

[Alexx83]

Well maybe someone whant to investigate it?

[pal100 rep0roc]

I tested both the newest Mesa build (11.2.0) and oldest (10.6.2) and both have the same issue. It appears that MSYS2 32-bit Mesa never worked.

I previously attempted to guess the 32-bit Mesa version included with QTCreator but I failed misserably. Should have used GLEW. It turned out to be a much older version (10.2.8).
But even so I was finally able to achieve my goal and avoid the annoyingly watermarked SwiftShader thanks to a performance boost introduced in Virtualbox 5.1. Now the rendering combi (Mesa software renderer 10.2.8 + WineD3D 1.7.52) produce a working D3D9 software renderer. Although it is very slow and demanding (can only run full speed at <500x500 - roughly a standard size player, any attempt to go beyond causes massive slowdown. full screen is out of the question, can still time out if host OS is a bit busy).

Important update:
MSYS2 Mesa3D 17.3.3 i686 is the first release in long time that doesn't crash anymore. This bug is finally fixed:
https://github.com/Alexpux/MINGW-packages/issues/2089#issuecomment-361540645