[PATCH] wined3d: Prevent buildup of retired buffer objects' memory.

[Jan Sikorski]

> On 20 Apr 2021, at 15:30, Henri Verbeet <hverbeet at gmail.com> wrote:
> 
> On Tue, 20 Apr 2021 at 11:37, Jan Sikorski <jsikorski at 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.

Right, that wouldn’t hurt even if it’s not that likely to happen, would you mind if I simply changed it to VkDeviceSize instead of doing overflow checks?

>> 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.

Sure