Re: [PATCH 0/1] MR2724: wined3d: Submit command buffers that are built for longer than 2 ms.

[Henri Verbeet (＠hverbeet)]

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