This improves performance for the game "Grounded", on a AMD Radeon RX 6700 XT,
with radv from Mesa 22.3.6. Testing was done with the "cb_access_map_w" option
enabled, which also improves performance with the game by itself.
From my testing, it's possible to raise the threshold from 2 ms up to 5 ms or
so, before the driver or GPU seems to reclock back to the lower power level.
However, this measurement is questionable for several reasons. It seems to vary
depending on the scene being rendered, and of course this will be specific to
the game and driver and GPU in question anyway. The game also has a weird
approach to vsync that seems to involve it presenting stale frames (and hence
artificially inflating the FPS), which I'm not fully sure I accounted for while
measuring. And of course, it's hard to be sure that 5 ms is actually the
threshold for how long the driver will go before powering down the GPU. In any
case, it seems better to err on the side of submitting more often, to make sure
the fix affects more drivers.
While submission isn't cheap, it seems to me that submitting every 2 ms is
unlikely to cause a bottleneck [consider that this is at most 8 (more)
submissions per frame].
The maximum of 4 concurrent periodically submitted buffers was chosen
arbitrarily. Removing the maximum altogether does not measurably affect
performance for this game either way.
Credit goes to Philip Rebohle and his work on DXVK for helping me to notice that
periodic submission might make a difference.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2724
On Mon May 15 21:29:55 2023 +0000, Zebediah Figura wrote:
> It may also be worth pointing out, for anyone looking for ways to do
> win32/unix interop using byte streams, that I believe it should already
> be possible using FIFO devices (i.e. mkfifo) and normal read/write.
> Granted, I haven't tested this, and maybe it's broken in some way or another?
Or, for that matter, a TCP loopback socket :-)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_32822
It may also be worth pointing out, for anyone looking for ways to do win32/unix interop using byte streams, that I believe it should already be possible using FIFO devices (i.e. mkfifo) and normal read/write. Granted, I haven't tested this, and maybe it's broken in some way or another?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_32819
> "Unfortunately, last time I tried to write tests for Unix sockets, I started triggering kernel panics in Windows." It seems like a Windows specific issue! A kernel panic should never occur, even when provided with invalid data.
Well... yes? I'm not sure what your point is.
> I think it's best to ignore Windows <-> Unix communications tests for now as I don't think `winetest` allow running tests in both Windows and Unix space at the same time, that would require `winetest` supporting `wsl` when testing on Windows10+, and I think `wsl` support is out of scope of this PR.
I'm not requesting tests for host interop here, and while I don't think it's a bad idea (for some measure of stability) we don't have the infrastructure to do those kinds of tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_32816