[PATCH vkd3d 2/2] vkd3d: Write a resource null descriptor to all applicable sets when one set is written.

[Henri Verbeet]

On Mon, 21 Mar 2022 at 16:25, Conor McCarthy <cmccarthy at codeweavers.com> wrote:
>
> Binding a shader with the wrong null descriptor type works in Windows. The
> introduction of Vulkan-backed heaps may cause a regression in clients which
> do this, because the written index will remain unpopulated in all other sets,
> but a shader may access it in one of them.
>
> Signed-off-by: Conor McCarthy <cmccarthy at codeweavers.com>
> ---
>  libs/vkd3d/resource.c | 55 ++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
>
Perhaps I'm just a bit "out of it", but it's not clear to me what "the
wrong null descriptor type" means above. I gather from the contents of
the patch that if we're writing a NULL descriptor at a particular
index we should also clear other descriptor types at that same index;
is that right? That would make sense, but I'd also imagine that would
be the case if we're writing a non-NULL descriptor. A test
demonstrating the issue would also be helpful, of course...

> @@ -2217,6 +2262,14 @@ static void d3d12_desc_write_vk_heap(const struct d3d12_desc *dst, const struct
>              ERR("Unhandled descriptor type %#x.\n", src->vk_descriptor_type);
>              break;
>      }
> +    if (is_null && device->vk_info.EXT_robustness2)
> +    {
> +        d3d12_desc_write_vk_heap_null_descriptor(descriptor_heap,
> +                descriptor_set->vk_descriptor_writes[0].dstArrayElement, device);
> +        vkd3d_mutex_unlock(&descriptor_heap->vk_sets_mutex);
> +        return;
> +    }
> +
So at the risk that I'm just not understanding the issue very well,
why does this need EXT_robustness2, and why is it limited to the case
where a NULL descriptor is written?