Created attachment 134011 [details] GPU Caps Viewer crash in randomly picked demo with OpenSWR - Visual Studio debug output screenshot I was trying to benchmark swr against llvmpipe using GPU Caps Viewer (http://www.geeks3d.com/category/geeks3d/gpu-caps-viewer-geeks3d/) as I observed some performance gain with v17.2.0 when testing with other software, but this didn't worked as planned. I got an instant crash on any demo I tried regardless of what OpenGL version the demo required. Initially I thought that GL 3.3COMPAT context enforced with MESA_GL_VERSION_OVERRIDE is the cause[1]. I thought maybe OpenSWR doesn't support this yet or it is buggy, but that doesn't seam to be the case. Even if I remove that from the batch script I wrote to pass variables to Mesa before launching GPU Caps Viewer and limit myself to GL 1.2 and 2.1 demos, I still get crashes for all demos, regardless of GL requirements being met or not. llvmpipe doesn't crash even if you attempt to start a demo for which llvmpipe doesn't meet the requirements. It fails cleanly. [1]I set MESA_GL_VERSION_OVERRIDE=3.3COMPAT for convenience as it allows running GL 1.2, 2.1 and 3.x demos without having to restart GPU Caps Viewer with GL 3.x content for GL 3.x demos and without for GL 1.2 and 2.1 demos.
Regression in 17.2.0. v17.1.8 is unaffected.
> Regression in 17.2.0. v17.1.8 is unaffected. I haven't had a chance to try it yet, but you're saying that 17.1.8 runs without crashing? That's helpful. Thanks.
Alex, how did you get GPU Caps Viewer to pick up the mesa libs? I tried copying the mesa libs to \windows\system32 (that works will other apps), but GPU Caps Viewer looks like it's doing something different.
Sorry, I didn't mention that GPU Caps Viewer is 32-bit even if running on 64-bit Windows so it goes in \windows\syswow64 on a 64-bit Windows. The way I get it to use Mesa is by copying or rather create symlinks to Mesa DLLs in the folder where GPU Caps Viewer resides; there is no DLL hijacking mitigation in place. I create symlinks instead of copying to save storage and to update Mesa from a centralized location, but you can do it as you want. Also I have an advice for you. Dropping Mesa3D DLLs in system32 is short lived. Only Windows 7 still allows this. Starting with Windows 8, Microsoft enlisted TrustedInstaller to have ownership over system files. Changing permissions of system files is bad idea if not impossible in Normal boot mode. However there is a way to apply Mesa3D system-wide even on Windows 8 and 10 in Normal mode, by hijacking the OpenGL ICD of the main GPU. Windows stores the filenames of all OpenGL ICDs in registry in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control under various keys which contain values named OpenGLDriverName for 64-bit ICDs and OpenGLDriverNameWow for 32-bit ICDs. The data of these values point to the OpenGL ICDs filenames.
Thanks Alex for the information on the dlls. While OpenSWR does not do anything special to explicitly disable 32-bit support, our team is not testing / developing on 32-bit. This is simply because our customer base is entirely on 64-bit, and the team does not have the manpower to support configurations that are not of interest to our customers. We certainly welcome community changes, and we have already done so in the past. Please feel free to contribute, if you so desire. Thanks!
I was able to replicate this crash with PPSSPP too. It crashes right away I could try Aida64 engineer and ePSXe, but something tells me they both would crash the same way. Probably 32-bit OpenSWR should be hard-blocked considering how awfully broken it is now.
PPSSPP 64-bit only crashes on exit. But that's probably something else.
Regarding PPSSPP 64-bit, please file a separate bug. However, please note these games (or game emulators) are not our current focus.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.