Remix attaches to CoherentUI instead of game renderer for GW2

[Malfrador]

Guild Wars 2 uses CoherentUI for certain browser-based UIs. The Coherent renderer is different from game renderer and runs as a separate process. When launching GW2 (running in DX9 mode with the -dx9 flag), Remix hooks into the CoherentUI renderer instead of the game executable (gw2-64.exe), presumably because Coherent launches first. The logs confirm that it indeed attached to CoherentUI_Host.exe. NvRemixBridge.log

The DX9 renderering mode is deprecated, but it seems likely to me that the same issue would occur with other games using Coherent or CEF in a similar setup.

Launching GW2-64.exe directly using the NvRemixLauncher made no difference. GW2 can load d3d9.dll files from both the main installation folder and the /bin64/ sub folder. I tried both, same result.

For developer reference, dx912pxy might be helpful, as it also redirects DX9 API calls (to DX12, not Vulkan) for GW2.

A way of specifying the exact process it should attach to might be useful to fix this issue. For example, NSight works fine with GW2 when using its feature for that.

[LauraWebdev]

Coherent is certainly one of the most used libraries for modern UI in Unreal.

[BSoD38]

I'm pretty sure GW2 is too recent for RTX Remix to work anyways. I highly doubt it uses a fixed-function pipeline.

[Malfrador]

I'm pretty sure GW2 is too recent for RTX Remix to work anyways. I highly doubt it uses a fixed-function pipeline.

the issue here is more that Remix seems to just attach to the process that starts first instead of the correct one. GW2 was just the only DX9 game I had installed that uses such a setup. It should try to use GW2, and then fail, as it does with other games.

GW2 (and 1) generate a lot of textures at runtime, mostly for NPCs and other players because of the way skins and dyes are implemented, and Remix likely won't work with that anyways. And yes, its mostly deferred rendering using shaders.