This affects 1.1.5.2 release of Vulkan-GL-CTS, for example the dEQP-VK.binding_model.buffer_device_address.set0.depth1.baseubo.load.nostore.single.std140.comp test.

This tests is being run only if VK_EXT_buffer_device_address Vulkan extension is supported, and constructs some shaders, that test this extension.

Before glslang change 90e402f, following code was emitted, which was correct:

OpExtension "SPV_EXT_physical_storage_buffer"

After this change, glslang emits:

OpExtension "SPV_KHR_physical_storage_buffer"

... which is a new extension, which is:

• not required to be supported by VK_EXT_buffer_device_address.
• not currently referenced in Vulkan 1.1 specification.

It seems we need a kind of knob, to revert glslang to previous behavior - without it any usage of
shaders targetig VK_EXT_buffer_device_address would be invalid.

Btw, Vulkan 1.1 spec says on VK_EXT_buffer_device_address:

This extension allows the application to query a 64-bit buffer device address value for a
buffer, which can be used to access the buffer > memory via the PhysicalStorageBufferEXT
storage class in the GL_EXT_buffer_reference GLSL extension and
SPV_EXT_physical_storage_buffer > SPIR-V extension.