Compatibility Report

• Name of the game with compatibility issues: Cities: Skylines
• Steam AppID of the game: 255710

System Information

• GPU: iGPU in i7-1165G7
• Video driver version: Mesa 24.0.0
• Kernel version: 6.5.0-17-generic
• Link to full system information report as Gist: https://gist.github.com/renatopereyra/9a8f9edc14197048d513d1f6d7e35b34
• Proton version: 8.0-5 and Experimental

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

Symptoms

When running on an Intel iGPU, Paradox Launcher does not always open when attempting to launch Cities: Skylines. Though this issue was initially observed in an ChromeOS Intel device, the symptoms reproduce in Ubuntu 23.10 devices with similar SOCs. This issue does not reproduce on ChromeOS or Ubuntu AMD devices. Logs and descriptions here are from Ubuntu to remain as generic as possible. This issue is ported from Mesa per request from @gofman.

I believe this issue originates from this line in ANGLE, which the Paradox Launcher is configured to use. The ANGLE link shows the logic ANGLE uses to determine whether it needs to require WGL_NV_DX_interop2 to render. Proton does not support this extension so whenever ANGLE determines that it needs it, rendering fails, which results in the Paradox Launcher failing to open.

Assuming I've root-caused the problem correctly, there are two situations in which ANGLE will not require WGL_NV_DX_interop2:

1. The GL_RENDERER/GL_VENDOR string corresponds to an AMD device (ANGLE vendor parsing here). It seems that ANGLE developers have determined that the AMD Windows GL driver has a bug with this extension so they work around internally and do not require it.
2. The render process owns the window that it needs to render to. I don't know how the render process or the window process are created so I don't know why this appears to be true only some of the time. However, I have done some experimentation that suggests that the faster the CPU is, the more likely it is that the render process will own the window as well, thus preventing this issue from reproducing.

Support for this root-cause diagnosis:

1. Proton logs from the i7-1165G7 (bad, not working): intel-steam-255710.log.zip. There are numerous instances across multiple TIDs of GL contexts being destroyed (wglMakeCurrent... newContext 0000000000000000) shortly before ANGLE windows are destroyed ("ANGLE Intermedi" [0002] WM_DESTROY sent from self).
2. Proton logs from a Ryzen 7 5825U (good, working): amd-steam-255710.log.zip. Only one thread ever destroys a GL context and there is no accompanying ANGLE window destroyed.
3. Steam stdout collected on the i7-1165G7 while launching Cities: Skylines with Proton 8.0-5: intel-steam-stdout-255710.log. There are multiple error logs indicating that ANGLE failed to initialize due to the missing WGL_NV_DX_interop2.
4. Forcing the GL_RENDERER and GL_VENDOR string to match "AMD" (example) works around the issue in the i7-1165G7.

Additional notes:

• Cities: Skylines defaults to Linux native but we use the Steam Deck compatibility tool mappings in ChromeOS so by default we are using Proton 8.0 for this game.
• I believe this issue would reproduce with an NVIDIA GPU if the GL vendor and renderer were not already overridden in Wine

Reproduction

• Launch Cities: Skylines with Proton 8.0 or Experimental on an Intel device multiple times. After the first launch, some of the time the launcher may never show or show only after a long time.

Yes, we should probably extend the override to Intel in this case for the present Proton hacks to work, similar to how that is currently done for Nvidia. I will look at a bit more details at some moment and fix that in Proton.

I propose these next steps:

1. Add a generic way to override the GL vendor and renderer in Wine.
2. Use (1) to and force AMD strings always for the Paradox Launcher.
3. Support WGL_NV_DX_interop2.
4. Remove (2) once (3) is done.

Optional, though I think would be good to have:

1. Dynamic overrides within hack_append_command_line via possible via env vars.

@gofman I'm happy to drive myself and put something up for review unless there is a preference against that.

Yes, sure, thanks! In that case I'd suggest to open PR to Proton/Wine against experimental_9.0 branch (https://github.com/ValveSoftware/wine/tree/experimental_9.0) and ping me there. I'd rename WINE_GL_HIDE_NVIDIA to WINE_GL_SPOOF_AMD (it is not autoset from anywhere besides the same function in winex11.drv/opengl.c), and change the condition so instead of checking for NVIDIA presence it would check for AMD absence.

I went with the name WINE_GL_VENDOR_REPORT_AMD for maximum clarity. PTAL

A fix for Intel GPUs merged into ValveSoftware/wine. I'll close this. I am independently looking into implementing WGL_NV_DX_interop2 into upstream Wine.

Probably doesn't make sense to close until it is in stable Proton (currently only in Proton Experiemntal [bleeding-edge] branch).

Yes, having the extension supported in upstream Wine is most interesting, if that is possible.

Do you by chance know of other usages of this extension beside game launchers?

No, I don't have any statistics of using it. Note that the launcher concerned here doesn't use it without a Proton hack forcing GL for CEF, otherwise the launcher uses Angle in d3d mode and doesn't use GL at all.