On 12/10/21 12:41, 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 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.
Cheers,
Yeah, considering that:
- winevulkan, opengl and potentially a bit of other stuff unfortunately have more issues for 32 on 64 without explored solution yet and even in the most optimistic case won't be there around 7.0;
- there is an example of the game which shows measurable performance drop;
- it is the last day before the code freeze and details are not yet known and it is not clear what fixing the performance drop will take.
I'd also suggest to explore that first without a rush.