```diff +static void perform_periodic_submit(struct wined3d_context_vk *context_vk) +{ + LARGE_INTEGER now, freq; + + assert(context_vk->current_command_buffer.vk_command_buffer); + + /* The point of periodic submit is to keep the GPU busy, so if it's already + * busy with 4 or more command buffers, don't submit another one now. */ + if (context_vk->current_command_buffer.id - context_vk->completed_command_buffer_id - 1 > 4) + return; ```
I suppose it's not worth worrying about, but note that in principle this would do the wrong thing if command buffer IDs were to wrap.
```diff @@ -1796,6 +1826,8 @@ static void adapter_vk_draw_primitive(struct wined3d_device *device, context_vk->c.transform_feedback_active = 0; }
+ perform_periodic_submit(context_vk); + context_release(&context_vk->c); }
@@ -1840,6 +1872,8 @@ static void adapter_vk_dispatch_compute(struct wined3d_device *device, VK_CALL(vkCmdPipelineBarrier(vk_command_buffer, VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT, 0, 0, NULL, 0, NULL, 0, NULL));
+ perform_periodic_submit(context_vk); + context_release(&context_vk->c); } ```
I suppose this is fine, but couldn't we just call perform_periodic_submit() from wined3d_context_vk_get_command_buffer()? We already handle WINED3D_RETIRED_BO_SIZE_THRESHOLD there, and it would largely avoid having to worry about where the ideal places to insert these calls are. (E.g., would a ddraw application that largely just does blits hit these in time?) It might be nice to use constants for "4" and "2000", much like how we have e.g. WINED3D_CS_QUERY_POLL_INTERVAL and WINED3D_ALLOCATOR_CHUNK_SIZE. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2724#note_31633