`is_layout_initialized` always returns false for several image types

[Rua]

@treeki asked me for some troubleshooting with Vulkano, because their image was being garbled after uploading it. We tracked down the API calls with RenderDoc, and found that whenever an ImmutableImage is recorded first into a command buffer, Vulkano inserts an image memory barrier that transitions the layout from Undefined to ShaderReadOnlyOptimal. This happens despite the image already having been uploaded and initialised properly with a separate command buffer/future. I confirmed that Vulkano's "image" example displays this behaviour too.

The ImageAccess trait has a method called is_layout_initialized, which is called by SyncCommandBufferBuilder to figure out if the image needs to be transitioned into another layout on first use. If so, then it inserts the aforementioned barrier and calls the layout_initialized method on the image. But for some reason, ImmutableImage and several other image types leave these two methods at their default, meaning that the former always returns false and the latter does nothing at all. Consequently, it inserts this barrier each time you use the image in a command buffer.

This behaviour has apparently been there since the olden days of Vulkano. So I am quite puzzled how this hasn't caused obvious problems until now, and I'm hesitant to make any changes in case it turns out it was made this way for a reason.

[Treeki]

The unnecessary transition from Undefined doesn't seem to break rendering in practice - at least on my current setup (Nvidia drivers on Windows 10), but it does break RenderDoc's replay engine which is a shame as it's very useful for debugging shaders. RenderDoc assumes that the Image has been discarded when it sees the spurious barrier.

I added the following method to the ImageAccess impl for ImmutableImage and it seems to fix the problem in my scenario:

    #[inline]
    fn is_layout_initialized(&self) -> bool {
        true
    }

With that addition, both the Vulkano 'image' example and my own project are now correctly debuggable in RenderDoc.

I don't understand enough about Vulkano's internals to know whether this is definitely safe, though - and it's possible that other types (like SubImage) could be subject to the same issue.

[marc0246]

This has since been fixed by #1833 and #2150.