On Tue, 20 Apr 2021 at 11:37, Jan Sikorski jsikorski@codeweavers.com wrote:
@@ -921,6 +921,9 @@ void wined3d_context_vk_destroy_bo(struct wined3d_context_vk *context_vk, const if (bo->map_ptr) VK_CALL(vkUnmapMemory(device_vk->vk_device, bo->vk_memory)); wined3d_context_vk_destroy_vk_memory(context_vk, bo->vk_memory, bo->command_buffer_id);
- if (bo->command_buffer_id == context_vk->current_command_buffer.id)
context_vk->retired_bo_counter += bo->size;}
Should we guard "retired_bo_counter" against overflow? On 32-bit builds that has a maximum of 4GiB, which is perhaps not as much as it once was in terms of VRAM.
diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index c3e3752ed71..694436ddad2 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -2549,6 +2549,8 @@ struct wined3d_context_vk VkCommandPool vk_command_pool; struct wined3d_command_buffer_vk current_command_buffer; uint64_t completed_command_buffer_id; +#define WINED3D_RETIRED_BO_COUNTER_THRESHOLD (64 << 20)
- size_t retired_bo_counter;
I'd prefer not having the WINED3D_RETIRED_BO_COUNTER_THRESHOLD #define in the middle of a structure. Perhaps next to the other allocator constants (i.e., WINED3D_ALLOCATOR_CHUNK_SIZE and the like) would be a good place. I think "retired_bo_counter" is perhaps a little awkward, in the sense that it doesn't count the number of retired bo's, but tracks their size; "retired_bo_size", perhaps?
In terms of the commit message, it's perhaps helpful to mention that one way this can occur is by the application doing resource updates without flushing either explicitly or implicitly, causing retired staging bo's for the current command buffer to accumulate.