From c558ff0e6d8f115a358df433a7789d457a808d38 Mon Sep 17 00:00:00 2001 From: Tomasz Kramkowski Date: Mon, 2 Nov 2026 21:48:27 +0000 Subject: Perf improvement hlvr patch --- hlvr/patch-hlvr | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'hlvr') diff --git a/hlvr/patch-hlvr b/hlvr/patch-hlvr index 5339157..d7b8d9d 100755 --- a/hlvr/patch-hlvr +++ b/hlvr/patch-hlvr @@ -69,6 +69,33 @@ def patch( PATCHES = { + "game/bin/linuxsteamrt64/librendersystemvulkan.so": patch( + "dc034f6b5d2116393bfead77f3265c124687b76766906c53a077c196b21ffa18", + "7a52bda8f4e6cc35e5ed46f181c3847400807704cab3fea38b40154d0b977f03", + ( + # The renderer keeps a pool of "staging" buffers that it uses to + # upload data to the GPU. When this pool exceeds 128MiB + # (configurable via RenderSystem.VulkanStagingPMBSizeLimitMB in + # "gameinfo.gi") of allocations, it will clear it down almost + # completely. This can take a good 30+ms which makes for a pretty + # unacceptable stutter. There's no need to clear all of it at once. + # This patch stops clearing when one staging buffer has been freed. + (0x22545D, "eb7b90"), + # When trying to re-use a staging buffer, the renderer only looks + # at two candidate buffers, and allocates (potentially triggering + # the de-allocation above) otherwise. Searching all the buffers + # seems fast enough and avoids constant allocation and + # de-allocation which seems slower. These patches implement that + # search. + (0x225B99, "0c496bc4504c8bb403980600004d89f290"), + (0x225BB8, "68"), + (0x225BC5, "5b"), + ( + 0x225C21, + "4183fc0675194d8b76104d85f675074c8bb3780800004d39d60f856affffff4531ffebb1", + ), + ), + ), "game/bin/linuxsteamrt64/libscenesystem.so": patch( "6d395e42a86d352eed03a794bb877f3fd21e84d4be494daa309ad986208e5c48", "7e47f2c0ba97e60cbedcb154df4017feaf04ad1d2528b942f46da15b7303bbc6", -- cgit v1.3.1