Intel's XeSS could use Arc's matrix units under Proton, but all four requests sit open
Four open requests filed on October 19 would let XeSS use the XMX matrix units on an Intel Arc card when a game runs under Proton, instead of the slower fallback path it takes there now. All four were opened by Damian Tomczak, whose GitHub profile lists Intel as his organisation, none of them has been merged, and Valve has said nothing about any of them.
The second shot in Forza Horizon 6's own Steam gallery. Steam publishes no description for any store screenshot. Image: Playground Games
The one in Valve's own tree is Proton pull request 10289, "xess xmx: Use a native libxess.so for XeSS when available", opened at 06:48 UTC against the bleeding-edge branch with five commits. Its description says it "makes Proton use the builtin libxess.dll from wine with a native libxess.so, so XeSS can use XMX", with Proton looking for that library in a variable the user sets, then in its own contrib directory, then in the system library path.
Wine, vkd3d-proton and DXVK carry the real work
The Wine half, pull request 369, adds a builtin libxess.dll that "forwards the XeSS D3D12 calls to the Linux XeSS library (libxess.so), so XeSS can use XMX (the fast upscaler) under Proton instead of the slower fallback path", converting D3D12 objects to Vulkan through vkd3d-proton's interop interface. vkd3d-proton 3379 then switches on the Vulkan extensions and features XeSS asks for, reading the list from XeSS itself and changing nothing if the DLL cannot be loaded.
The third shot in Forza Horizon 6's own Steam gallery. Image: Playground Games
The DXVK request is the revealing one. Pull request 5992 says DXVK carries a vendor workaround that hides an Intel GPU from any game whose libxess.dll is older than 2.0.2.68, and that Proton's copy of that DLL "is a Wine builtin forwarding to the Linux XeSS library, it has no version resource, so the check always failed and the Intel GPU was hidden". The dxgi.hideIntelGpu option still overrides the new behaviour.
Only two of the four repositories are Valve's. vkd3d-proton and DXVK are separate projects that Proton pins as submodules, which is why the author writes that the Proton request "bumps the other three submodules, so it should go in last". That route can be fast when the pieces land: a DXVK fix for an EA anti-cheat crash turned up in a Proton bleeding-edge build six hours after it merged.
The fourth shot in Forza Horizon 6's own Steam gallery. Image: Playground Games
Nothing has merged, and the code predates the requests
The Proton request has no review and one comment, from its author, listing the series. The code it carries is older than the request: the Proton commit, c89e3cc, is authored by Caleb Callaway from an intel.com address and dated September 10, five and a half weeks before anything was filed, and it adds 114 lines to a single file.
None of the four carries a benchmark, a frame rate, a game list or a word about which Arc generations gain anything. The only claim on the record is the requests' own, that the change lets XeSS reach XMX, and none of them links to anything Intel has published.
Intel's upscaler has not been predictable on Windows either, where its frame generation override does not engage until the game's own setting is on. On Linux the position is simpler: the four requests are open, Valve has not replied to the Proton one, and no Proton build carries any of this yet.
