Replacing ID3D11Device::OpenSharedResource. Is it possible?

FiveM Discussion
1

I’d like to preface my post with stating that I’m not really familiar with how FiveM works internally and it’s critically important to me for FiveM to work with wine and dxvk.

From what I’ve read on dxvk’s github and Phoronix, implementing ID3D11Device::OpenSharedResource in dxvk is technically possible, but is a pretty massive effort and no one is currently working on it since this function is used very rarely.

So I’d like to explore a different approach. How serious of an undertaking would it be to replace all the calls to ID3D11Device::OpenSharedResource in FiveM? I’ve grepped the codebase to find all call sites and there’s like 4 of them total and one is simply a stub, so 3 real calls total.

From what I can gather (correct me if I’m wrong), the function is used to obtain a memory address where (texture?) data is held to “do something with it”, populate some memory that’s further processed or something.

Does any other way currently exist to obtain same addresses/data/whatever this code supplies without relying on this specific function call? Like reading process memory manually, or using windows API or copying and patching game’s binaries directly at assembly language level or… anything really?

If it does not, how hard would it be to write such functionality from scratch?

1 Like
2

As you linked, some CodeWeavers employee made some progress on a patch series to implement underlying Vulkan support for D3D handles but it’s been fairly quiet on that front since then… this patch never landed on main Wine or -staging, also seems incomplete without additional shared memory from a high-level graphics API implementation to contain metadata.

Not using shared resources would lead to a crippled game since we use this for out-of-process isolation of game/browser/frontend state which a lot of subsystems rely on… it’s also a core feature of the DirectX graphics infrastructure, so implementing that Wine patch + an implementation of the API on top of DXVK/whatever-you-use would be a minimum requirement to have the game working - there’s no workaround or other similar API for sharing GPU-side memory across processes, however it should be trivial with coordinated Wine/DXVK work to implement this on top of VK_KHR_external_memory_fd, as I saw last the state was just DXVK maintainers whining no work was done on the Wine side, the Wine side not landing this patch, and a lot of spectators complaining ‘FiveM sucks anyway, why would you want it to work, nothing else uses this API’.