fix(graphics): resolve launchers to DXVK on every runtime - #252
Merged
Conversation
The resolver only steered launchers away from D3DMetal, so on a runtime without the D3DMetal payload a Steam launch resolved to DXMT. Chromium cannot render on DXMT any more than on D3DMetal: the CEF gpu process fails to create its window swapchain and the client runs with no window. Confirmed on v4.6.4-beta.1 against a real Steam bottle; details on #163. Launchers now resolve to DXVK unconditionally, before any backend availability logic. Games a launcher starts are unaffected: the steer keys on the launched executable, not the bottle.
frankea
force-pushed
the
fix/launcher-backend-resolution
branch
from
September 1, 2026 05:38
4f64efe to
8197f57
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Owner
Author
|
Review notes (self-merge per the usual flow, so on the record here): the behavior change is exactly the launcher hoist; games and default-argument callers are untouched, which the kept tests pin down. The deleted test asserted the buggy behavior by name, and its replacement encodes the corrected rationale with the DXMT-available fixture, so the regression cannot come back silently. Verified against the live failure this fixes on v4.6.4-beta.1 before writing the patch: a clean Steam bottle resolving to DXMT never shows a window, and the same bottle on DXVK presents. Full kit suite green locally and on CI. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GraphicsBackendResolver.resolve(for:)only diverted launchers to DXVK inside thed3dMetalInstalledbranch. On a runtime without the D3DMetal payload (every default install of the new engine line), a Steam launch resolved to DXMT. Chromium cannot render on DXMT any more than on D3DMetal: the CEF gpu process fails to create its window swapchain (SwapChain11.cpp:636,HRESULT: 0x80004005,eglCreateWindowSurface: EGL_BAD_ALLOC) and the client runs headless with no window. Confirmed twice on clean bottle clones againstv4.6.4-beta.1; full investigation on #163.The DXMT launch also deploys a native
dxgi.dllinto the prefix that later poisons DXVK launches; that residue is a separate fix in the follow-up PR.Fix
The launcher check moves to the top of
resolve(for:): a launcher always gets DXVK, regardless of what else is installed. Games a launcher starts are unaffected (the steer keys on the launched executable).Tests
testLauncherIsNotSpecialWithoutD3DMetalasserted the buggy behavior and is replaced bytestLauncherGetsDXVKWhenDXMTWouldBeRecommended(game resolves DXMT, launcher resolves DXVK on the same runtime) andtestLauncherAndGameAgreeWhenOnlyDXVKExists. Full kit suite passes.Part of #163.