[Feature Request] Executable black list

[ghost]

I would like to see a black list for executables, development tools often suffer greatly from poor performance with dxvk enabled.

Example is GECK for Fallout 3 and New Vegas, the render window takes 5 minutes (!) to initialize instead of a couple of seconds.

3ds max also has problems with rendering and initializing.

[doitsujin]

How is crashing because we're blacklisting certain apps better than just using wine's built-in DLL override features?

[doitsujin]

To be clear, if your idea was to make it forward to wined3d for blacklisted apps instead, we can't do that on our end since we're replacing the DLLs, effectively making DXVK the only available implementation of d3d9 etc from an app point of view (as well as its own). wine's built-in DLL override mechanism will however still load wined3d if you set d3d9 or d3d11+dxgi to builtin and can be configured per application.

[ghost]

Hi doitsujin! While I realize dxvk is primarily for use with wine on Linux, a non-zero number of people use it on Windows as well as it can improve performance in some situations. For example dxvk has been uploaded to the Fallout New Vegas Nexus as "FNVulkan", which I understand your license permits, but the result is basically that a lot of people place a d3d9.dll from dxvk in the root folder with FalloutNV.exe - this means it applies to GECK.exe in the same folder. I realize this is outside the scope of what would constitute an actual issue with dxvk itself, but if you'd be so kind as to point in me in the right direction anyway, is there any equivalent to the "DLL override mechanism" you described that could be used in this type of Windows environment? Regards, Liam

[doitsujin]

I don't really know how to solve this with Windows internals, but I feel like this is the kind of inconvenience you'll just have to live with for now. Since we're not hooking D3D libraries like (most) actual mods do but rather reimplement the whole thing, it's not that simple.

In theory we could proceed to load the system32 library and forward our D3D9 entry points to that on Windows, but a) i'd rather figure out why the app in question takes 5 minutes to load and b) it would do a lot more harm than good on the wine side of things since we (usually) are the system32 implementation in that case.

[qinlili23333]

but the result is basically that a lot of people place a d3d9.dll from dxvk in the root folder with FalloutNV.exe - this means it applies to GECK.exe in the same folder.

I'm not sure whether you are still waiting for some help, but I have recently faced similar issue and I suggest to use Detours to solve this issue. Just use Detuours to hook LoadLibrary functions, and use GetModuleFileName to check what's current executable, then redirect to actuall path of dll in hooked function (for native dll, just modify the path to system32 and call original LoadLibrary). You can use any dll loaded by both processes to hook, like version.dll. You can also consider to use advanced DLL search skills like SetDllDirectory as document (https://learn.microsoft.com/zh-cn/windows/win32/dlls/dynamic-link-library-search-order).