On 12/10/21 10:41 AM, Rémi Bernon wrote:
On 12/10/21 10:37, Derek Lesho wrote:
On 12/10/21 10:26, Rémi Bernon wrote:
On 12/10/21 03:07, Jacek Caban wrote:
To allow them being accessed from a struct.
Signed-off-by: Jacek Caban jacek@codeweavers.com
v2: make remaining direct calls more similar to __wine_unix_call
dlls/winevulkan/make_vulkan | 59 ++++++++++++++++++++----------------- 1 file changed, 32 insertions(+), 27 deletions(-)
Thanks, it indeed fixes the issue with Control DX12.
Now that it works I could measure that the series causes a ~25% fps drop in that same game, from an average of 165fps to 125fps measured with WINEDEBUG=+fps, while being steady near the beginning of the game.
Maybe this could wait after 7.0 and take some more time to explore possible mitigations?
Would sending patches during the code freeze optimize this path count as regression fixing? 😅
I guess, but I don't really see why this would be critical to include now, I believe Wine 7.0 will still be missing critical pieces to make winevulkan wow64 usable.
I don't think this is critical. The most important parts of the series were committed yesterday and with them, we no longer need old style Unix libs. The rest would be still nice to have. Even if we don't enable syscalls for everything, it would be nice to be prepared for them.
BTW, wow64 is not everything. For example, the patchset avoids Windows debuggers being confused by Vulkan calls.
I also wouldn't bet on it being easily possible and in a way that's acceptable for the code freeze (ie: without too many or ugly changes).
It would also imho impede an eventual Proton rebase, as we'll not want that kind of regression so we'd probably have to revert the changes, and not even try to fix the regression or make some ugly hacks to workaround it.
Note that only the last patch from the series is risky for performance. That patch is also small and easy to tweak or revert, if needed, so I'm sure we will not anything uglier than that. Maybe we could just disable it for command buffer (and possibly some other frequent calls) for now and have the codebase otherwise ready and tested.
Thanks,
Jacek