search

pal1000 / mesa-dist-win

Pre-built Mesa3D drivers for Windows
MIT License
916 stars 80 forks source link

regression 22.0.3 → 22.1.0 crash on Server 2012 R2 and 2016 #121

Closed Optiligence closed 1 year ago

Optiligence commented 1 year ago

Hi i’m using this to get better OpenGL support for CI builds on appveyor. Running 22.0.1 on Windows Server 2012 R2, 2016 and 2019 works well (msvc build). Updating to 22.2.2, however, only 2019 works. 2012 R2 and 2016 result in

Command exited with code -1073741819

Happens with both, the msvc as well as the mingw build.

One thing i noticed is that the renderer in 2019 now shows

4.2 (Compatibility Profile) Mesa 22.2.2 (git-16d3384210), Microsoft Corporation, D3D12 (Microsoft Basic Render Driver)

instead of llvmpipe.

pal1000 commented 1 year ago

Does setting GALLIUM_DRIVER-llvmpipe help? Do you have LIBGL_ALWAYS_SOFTWARE=1 set?

Directox01 commented 1 year ago

@Optiligence May I ask if you have tested it on Server 2019 or 22?

Optiligence commented 1 year ago

setting either GALLIUM_DRIVER=llvmpipe or LIBGL_ALWAYS_SOFTWARE=1 avoids the issue ref https://ci.appveyor.com/project/knossos/knossos/builds/45245427

The newest available image is Visual Studio 2022 which runs Server 2019.

It seems to be a problem since 22.1.0 ref https://ci.appveyor.com/project/knossos/knossos/builds/45245909

pal1000 commented 1 year ago

It appears that gallium D3D12 driver tries to run when it can't. Server 2012 R2 and Server 2016 are bellow the minimum requirements for it to run. What's odd is that it tries to run without LIBGL_ALWAYS_SOFTWARE=1 being set and it doesn't when LIBGL_ALWAYS_SOFTWARE=1 is actually set. Could it be that AppVeyor instances have at least 1 D3D12 capable GPU?

In any case you can set GALLIUM_DRIVER=llvmpipe to make sure you use llvmpipe even on Server 2019 and up. You can ditch LIBGL_ALWAYS_SOFTWARE=1 afterwards as it only makes sense for d3d12 and zink.

Bring @jenatali into discussion. It's also a good idea to report this issue upstream.

jenatali commented 1 year ago

Server 2012 should just fall back after trying to load D3D12.dll and failing. Server 2016... If I'm remembering my history right should have a version of WARP (Windows software rasterizer) that supports D3D12, but that might've been added later. I think the Mesa D3D12 gallium driver requires some newer stuff than would be in server 2016 anyway.

If you're able to provide call stacks and/or crash dumps, preferably to Mesa issue tracker, I can take a look.

Optiligence commented 1 year ago

it seems to be resolved with 22.3.0 uses llvmpipe again for 2012 R2 and 2016 without any configuration

@jenatali sorry i didn’t get to debug this further; trying to do that via ci configuration can get annoying pretty quick

thx all for the engagement (and possibly for the fix)