Clarification about the `Alignment` decoration in `VK_EXT_descriptor_heap` proposal

[Cyphall]

The VK_EXT_descriptor_heap proposal says:

Vulkan-Docs/proposals/VK_EXT_descriptor_heap.adoc

Lines 340 to 342 in ac8223b

	Device addresses in push data are intended as the replacement fast path for `VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC` and `VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC`.
	Note however that as they are not buffer descriptors and no size is provided, robust buffer access does not apply; out of bounds accesses are invalid.
	In order to maximize performance of constant data inputs, addresses should be aligned to `minUniformBufferOffsetAlignment`, and decorated with `Alignment` and `NonWritable` in the shader when using physical pointers.

According to the SPIR-V spec, the Alignment decoration is only available with the Kernel capability (OpenCL).
Is this intended?

I thought the author could have meant to use the Aligned decoration instead, but this one is specified on the OpLoad directly and only the first member of a struct is guaranteed to have the same alignment as the struct, so the drivers probably cannot rely on this to determine the alignment of the pointer (in cases where the first member is never loaded).

[Tobski]

Well, whoops. I think I just missed the Kernel capability requirement. I think this bit just needs to be deleted for now. I'll raise a change internally.

[oddhack]

This should be fixed in the 1.4.343 spec update.