search

pal1000 / mesa-dist-win

Pre-built Mesa3D drivers for Windows
MIT License
859 stars 77 forks source link

SOMA crashes with Zink. #160

Open Erquint opened 8 months ago

Erquint commented 8 months ago

Windows 10x64. NVidia graphics.

Trying to wrap SOMA by Fricional Games to convert its OGL calls to VK. Doing this to see if that would streamline whatever awful asset streaming code the game uses. At some point during save loading from the main menu, memory access violation occurs. Dereferencing a null pointer, seems like. Here's the crashdump.

Tried both the weird symlinking script you provide, agreeing to pretty much all options, as well as manually copying just the opengl32.dll, libgallium_wgl.dll and libglapi.dll from the x64 directory and permanently setting GALLIUM_DRIVER=zink, MESA_GL_VERSION_OVERRIDE=3.3COMPAT for the user along with required restarting of the parent launcher to have it reload the envars. Unsure if the value of the second envar makes sense but had no luck without it either.

Checked with Dependency Walker and nothing looks criminal there.

Oh, and when using RTSS to report the API used, after the initial loading of the game itself progresses far enough, the readout starts flashing between "OGL" and "VULKAN" in the main menu.

pal1000 commented 8 months ago

Please report upstream. In addition to the dump a call stack may be necessary.

Erquint commented 8 months ago

Care to clarify? Isn't the call stack derived from the dump? As for upstream — isn't that geared towards Linux?

pal1000 commented 8 months ago

Isn't the call stack derived from the dump?

Probably but without debug symbols the call stack only includes function names and memory offsets. It lacks more useful info like source code file path(s), line(s) where exception happened, variable(s) name(s) and value(s) at exception time. Without this vital information you risk your issue report to be ignored indefinitely. I provide debug symbols for MSVC build in debug info package and drop in replacements debug MinGW binaries.

As for upstream — isn't that geared towards Linux?

That is no longer true since VmWare began using llvmpipe on Windows since circa 2010 as part of their virtualization stack on systems not eligible for virtual GPU OpenGL hardware acceleration, then Microsoft got in the game with drivers layered over d3d12 providing OpenGL, OpenCL, Vulkan and VA-API and roughly in parallel Collabora developers introduced an OpenGL over Vulkan layered driver called zink that quickly got Windows ,support.