[Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()

Samuel Pitoiset samuel.pitoiset at gmail.com
Tue Jun 11 12:41:17 UTC 2019


On 6/11/19 12:19 PM, Samuel Iglesias Gonsálvez wrote:
> On 6/11/19 12:05 PM, Józef Kucia wrote:
>> On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
>> <siglesias at igalia.com> wrote:
>>> According to the Vulkan spec, uniform blocks are not allowed to be
>>> updated through vkCmdPushDescriptorSetKHR().
>>>
>>> There are these spec quotes from "13.2.1. Descriptor Set Layout"
>>> that are relevant for this case:
>>>
>>> "VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
>>>   that descriptor sets must not be allocated using this layout, and
>>>   descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
>>>
>>> "If flags contains
>>>   VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
>>>   elements of pBindings must not have a descriptorType of
>>>   VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
>>>
>>> There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
>>> this case but it is implied in the creation of the descriptor set
>>> layout as aforementioned.
>>>
>>> Signed-off-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com>
>>> ---
>>>
>>> My only doubt is I did well in the case of
>>> radv_meta_push_descriptor_set(), let me know if you prefer to change
>>> it to false.
>>>
>> Perhaps I'm missing something, but what is the point to add the
>> additional checks for invalid usage? A correct program must not use
>> inline uniform blocks with push descriptors.
>>
> Right, it should be detected by the Validation Layers. However it is
> arguable what to do in the driver's side. We can just keep it as it is
> now, ignore inline uniform block updates (this patch) or even add an
> assert if it affects stability of the HW (it is not the case here, we
> tested it). I think ignoring the updates it's the best option, but I am
> OK with what RADV developers prefer to do.
Adding an assertion looks better to me as well.
>
> Sam
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190611/8bc5b26e/attachment.html>


More information about the mesa-dev mailing list