Requirement of support for compatible per-plane formats when a multi-plane format is supported

[maxime-modulopi]

From what I read in the specs, when an implementation supports a multi-plane format, it is not required to also support the compatible per-plane formats of this multi-plane format.

This can lead to a situation where it is impossible to create valid single-plane image views from a multi-plane image (see GPUOpen-Drivers/AMD-Gfx-Drivers#46).

Should this requirement be added to the specs?

[fluppeteer]

Apologies for the delay; the original intent was that creating an alias of a single-plane view was only supposed to be an option for disjoint multi-planar images, since otherwise the relationship between the planes may be complicated (especially for some layouts). I'm spelunking to check that no deliberate change was made here, but I'll try to get a clarification MR in the spec assuming that this intent hadn't changed.

[maxime-modulopi]

since otherwise the relationship between the planes may be complicated (especially for some layouts)

I thought multi-planar images were basically multiple (physically or logically) separate images glued together under a single handle (and with some additional features such as auto YCbCr conversion), in which case supporting single-plane views should be straightforward to implement.

Our graphics library uses a fully bindless + single VkPipelineLayout design so I can't really integrate YCbCr samplers.

[fluppeteer]

Only if they're disjoint. There are formats that have interleaved/interlaced planes and implementations that have specific offset requirements between planes (often the ones which don't need multiple samplers...) which mean that you can't treat the planes separately. That distinction is what disjoint was for.

[maxime-modulopi]

By "interleaved/interlaced planes", do you mean formats like VK_FORMAT_G8B8G8R8_422_UNORM?
If so, the specs treats such formats as single-planar, in which case I should already be able to read them via e.g. a VK_FORMAT_R8G8B8A8_UINT image view.

For the disjoint vs non-disjoint part, this is unfortunate, I really thought all implementations would be able to read planes separately since these planes are contiguous in memory...

Anyway, thank you for the explanation.

[maxime-modulopi]

Furthermore, shouldn't creating single-planar image view of multi-planar images be forbidden if the multi-planar format does not support VK_FORMAT_FEATURE_DISJOINT_BIT?
I believe the only restriction at the moment is that the single-planar format of the image view must be compatible with the selected plane of the multi-planar image format (VUID-VkImageViewCreateInfo-image-01586).

[fluppeteer]

(Sorry for the delay, btw.)

By "interleaved/interlaced planes", do you mean formats like VK_FORMAT_G8B8G8R8_422_UNORM?
If so, the specs treats such formats as single-planar, in which case I should already be able to read them via e.g. a VK_FORMAT_R8G8B8A8_UINT image view.

I've seen implementations that have, for example, a 16x16 tile of Y' stored contiguously with 8x8 Cb and 8x8 Cr, as a repeating tile. If you're doing aligned DCTs as part of video or image decode, that's not an inefficient approach. Obviously it's not "linear", though! Real world situations can be worse (actual interlacing theoretically aligns luma with the associated chroma from the same field, not the same image - and when a video stream switches format, you can end up with some blocks interlaced and some not, which is as horrible as it sounds to try to deal with efficiently; fortunately interlacing is outside Vulkan's remit, at least for the chroma conversion).

It's possible that all current Vulkan implementations actually do support disjoint, but this certainly wasn't the case historically.

Furthermore, shouldn't creating single-planar image view of multi-planar images be forbidden if the multi-planar format does not support VK_FORMAT_FEATURE_DISJOINT_BIT?

Yes, it should.

I believe the only restriction at the moment is that the single-planar format of the image view must be compatible with the selected plane of the multi-planar image format (VUID-VkImageViewCreateInfo-image-01586).

I think the wording got mangled at some point in the past - the idea was that you could pick any format that's compatible with the plane, but accessing the plane in the first place was only supposed to be supported with disjoint. I think all this predated VUs in the spec, so it's possible that a restriction got misinterpreted as being redundant and got removed.

Thanks for bringing this up, because it's clearly become broken. I'll try to get some wording together to fix it!

[maxime-modulopi]

Furthermore, shouldn't creating single-planar image view of multi-planar images be forbidden if the multi-planar format does not support VK_FORMAT_FEATURE_DISJOINT_BIT?

After thinking a bit more about that, I think something else should be used instead of VK_FORMAT_FEATURE_DISJOINT_BIT.
On AMD (W6600), I can successfully read the planes of a VK_FORMAT_G8_B8R8_2PLANE_420_UNORM image separately even though this format does not report VK_FORMAT_FEATURE_DISJOINT_BIT, so some implementation can still support this usage even for non-disjoint images.

[fluppeteer]

After thinking a bit more about that, I think something else should be used instead of VK_FORMAT_FEATURE_DISJOINT_BIT. On AMD (W6600), I can successfully read the planes of a VK_FORMAT_G8_B8R8_2PLANE_420_UNORM image separately even though this format does not report VK_FORMAT_FEATURE_DISJOINT_BIT, so some implementation can still support this usage even for non-disjoint images.

It's been quite a few years since I was involved in the original language, but this sounds like a driver bug. :-) I'll spelunk for a bit and see whether this can get clarified. Thanks for letting us know that either something has changed, or the wording has atrophied.

[maxime-modulopi]

To me, being able to bind planes to separate allocations and being able to read planes separately in shaders look like two very distinct capabilities. I can totally imagine an implementation being able to do the latter even if the former is not possible due to e.g. complex interlaced plane layout.
This is why I was suggesting that exposing both capabilities through the same VK_FORMAT_FEATURE_DISJOINT_BIT flag may not be the right solution.

[fluppeteer]

Oh, sorry, I see what you mean. Yes, you're probably right. Let me remind myself how all this works (we agreed it all in 2017...) and I'll see what we can rationalise.