vulkan validation error: VUID-vkAllocateMemory-deviceCoherentMemory-02790

[FlorianUekermann]

I see the following vulkan validation error on master, but no visual issues:

    VALIDATION [VUID-vkAllocateMemory-deviceCoherentMemory-02790 (-2010063723)] : Validation Error: [ VUID-vkAllocateMemory-deviceCoherentMemory-02790 ] Object 0: handle = 0x55b416ae07b0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x8830dc95 | vkAllocateMemory: attempting to allocate memory type 4, which includes the VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD memory property, but the deviceCoherentMemory feature is not enabled. The Vulkan spec states: If the deviceCoherentMemory feature is not enabled, pAllocateInfo->memoryTypeIndex must not identify a memory type supporting VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkAllocateMemory-deviceCoherentMemory-02790)
    object info: (type: DEVICE, hndl: 94231962978224)

I suspect the culprit to be this call:

         device.create_buffer(&wgpu::BufferDescriptor {
            label: None,
            size: std::mem::size_of_val(&entity_uniforms) as u64,
            usage: wgpu::BufferUsage::UNIFORM | wgpu::BufferUsage::COPY_SRC,
            mapped_at_creation: true,
        })

Without a way to panic on validation errors, tracking down the source is a little cumbersome. If needed I can provide a trace.

[kvark]

Oh yes, I recall seeing this. I believe it's a bug in the validation layer: we are creating a Vulkan 1.0 instance and not enabling "VK_AMD_device_coherent_memory" extension (which defines VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD), so reporting any misuse of that is an error on their part.
I think they just don't have a proper Vulkan version check, since the extension became core in Vulkan 1.1.

[FlorianUekermann]

Mmh, this makes debugging rather annoying in practice, so I'm tempted to escalate this. But first I would like to be somewhat certain that this is actually a bug in the validation layers. Right now I'm confused.

• I assume the deviceCoherentMemory feature is not enabled
• The gfx backend for vulkan seems to allocate memory of a type that has the VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD bit, which triggers this validation error
• The Vulkan 1.0 spec seems to say here, that allocation is simply not allowed.
• Your interpretation of the spec seems to be that since the extension isn't enabled, gfx doesn't need to observe this restriction, because it doesn't even know about the relevant bit.

I wasn't able to check in the spec how extra set bits in the memory properties are supposed to be interpreted (ignore the bit or don't use the memory type). Furthermore, the description of the extension seems to suggest that this memory will be really slow under most circumstances, so this may be a performance bug in practice.

I see a few options:

1. the validation layer is wrong, as @kvark suggested
2. the driver (RADV) shouldn't offer this memory, because the extension isn't enabled
3. gfx shouldn't use this memory because that "unknown" bit is set
4. 1 or 2, but gfx should be made aware anyway because the performance is going to be terrible

[kvark]

I assume the deviceCoherentMemory feature is not enabled

Correct, we don't know about this feature, since it's a part of the extension we don't care about ("VK_AMD_device_coherent_memory"), and we don't enable it.

The gfx backend for vulkan seems to allocate memory of a type that has the VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD bit, which triggers this validation error

We don't even see this bit. It just happens to be in properties of one of the memory types we use.

The Vulkan 1.0 spec seems to say here, that allocation is simply not allowed.

The spec forgets to mention that for this to not be allowed, you either need to opt into the extension, or run on Vulkan-1.1 and higher.

So what I think might be happening is:

1. the spec authors forgot to mention that it's an extension
2. LunarG implemented the validation blindly wrong

If we reach out to LunarG now, they can bounce back saying that the spec is written this way. Therefore, I created KhronosGroup/Vulkan-Docs#1298 for the spec to be fixed first.

[kvark]

@FlorianUekermann comment gfx-rs/gfx#3221 (comment) indicates that the validation layer was fixed. Could you check if that's the case for you as well?

[FlorianUekermann]

I updated to 1.2.135, which was release 4 days before that comment. Now I get UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotUpdated on top of the error in this issue. There was a new release a few days ago, I'll try that as soon as Rawhide updates the package.

Is this the right repo to report these issues, or should I report them on gfx?

[kvark]

This repo would be the right one.

[kvark]

I'm going to close this as the gfx-rs changes have been merged in gfx-rs/gfx#3297
Please do cargo update -p gfx-backend-vulkan and re-open if the issue persists.