Layers: Resource binding and aliasing checks may be too strict

[yavn]

I'm observing errors related to keeping track of allocated memory and resource types that were bound to it. Layers are making assumptions about how the memory range is going to be used by the app and emit errors when the usage pattern seem to be incorrect.

1. Binding a memory range that was also bound to a resource with a different tiling

MEM(ERROR): object: 0xb type: 9 location: 0 msgCode: 3: Linear buffer 0xb is aliased with non-linear image 0x9 which is in violation of the Buffer-Image Granularity section of the Vulkan specification.

Although the layer is trying to highlight what is most likely a bug, there's no spec language (AFAIK) that says this is an error. Violating buffer-image granularity makes the resources alias each other, and aliasing of linear and non-linear resources makes reads/writes undefined to the other resource. So this should probably be a warning instead.

2. Mapping a memory range that is aliased with an unused image

DS(ERROR): object: 0x0 type: 0 location: 11197 msgCode: 6: Cannot map an image with layout VK_IMAGE_LAYOUT_UNDEFINED. Only GENERAL or PREINITIALIZED are supported.

MEM(ERROR): object: 0xf type: 10 location: 0 msgCode: 3: Non-linear image 0xf is aliased with linear image 0xcccccccccccccccc which is in violation of the Buffer-Image Granularity section of the Vulkan specification.

The layer is tracking bound memory ranges and sees that a range is used by an image that was never transitioned from UNDEFINED layout. But this message is a false positive. We're actually mapping the range in order to access a buffer that aliases the image. The image itself is never accessed. Of course there's no way to tell the intent, as this is not visible in the vkMapMemory call... Not sure if this can be improved. Again, layer is trying to do the right thing here, but in presence of aliasing this is just too ambiguous.

The second message outputs an uninitialized variable (0xcccccccccccccccc) because a common code is used that expects image handle but we only set memory range before calling. This is a small bug, not really relevant.

For reference, the Khronos internal Vulkan CTS issue for this is 560 if you want to see the test that causes these problems.

[tobine]

@yavn Thanks for the bugs and great analysis. I agree that the first needs to change to a warning. The spec language is only telling what you must do to avoid aliasing, but isn't saying that the aliasing in itself is an error.

For the second case I'll leave as an error for now but see if I can at least clean up the printing of un-initialized variable in the near-term.

Longer-term I'd like to keep this open and analyze if we can be a bit smarter about the second aliasing case. I think it's probably a very rare case so don't want to spend too much effort on it, but may be some simple updates that can be made to at least make validation more friendly in this case.

[tobine]

#1264 makes this better. Lowering priority.

[yavn]

Thanks. For reference, there was a similar issue here: #328

[karl-lunarg]

Fixed via KhronosGroup/Vulkan-ValidationLayers#14