| Summary: | swr: 32-bit binaries crash any app I use with them | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | pal1000 <liviuprodea> |
| Component: | Drivers/Gallium/swr | Assignee: | mesa-dev |
| Status: | RESOLVED WONTFIX | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | george.kyriazis |
| Version: | 17.2 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | GPU Caps Viewer crash in randomly picked demo with OpenSWR - Visual Studio debug output screenshot | ||
|
Description
pal1000
2017-09-06 15:45:39 UTC
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.