<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Using a single-plane imageview from a multi-plane image is broken" href="https://bugs.freedesktop.org/show_bug.cgi?id=105496#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Using a single-plane imageview from a multi-plane image is broken" href="https://bugs.freedesktop.org/show_bug.cgi?id=105496">bug 105496</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to atomnuker from <a href="show_bug.cgi?id=105496#c24">comment #24</a>) > (In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c23">comment #23</a>) > > Digging through the khronos gitlab, it seems the extended flags was added > > for another purpose : > > <a href="https://gitlab.khronos.org/vulkan/vulkan/merge_requests/1896">https://gitlab.khronos.org/vulkan/vulkan/merge_requests/1896</a> > > > > I think the usage you describe looks like it would fix atomnuker's problem, > > but it feels like an unintended consequence :) > > Well, the EXTENDED usage flag is for when your imageview's format is > supported by the GPU but the format the image was created with is not. It > only applies to formats, rather than usage flags, tiling, etc. > The flag to be able to create single-plane representations of multi-plane > images is VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT. That's utter nonsense. It exists precisely for cases like this where to have an image in a format that supports some limited usage flagss but you want to create a view of it in a compatible format has greater usage flags which you want to take advantage of. Originally, the purpose was to combine it with another flash and allow creating uncompressed views of compressed textures so that you can write a texture compressor in a compute shader. However, it also seems to apply quite nicely here. > > That said, the interaction here between VK_KHR_maintenance2 and > > VK_KHR_sampler_ycbcr_conversion is a bit subtle so I'm not that > > surprised that both of you (along with the CTS authors) missed it. > > There should be no interaction between either, maintenance2 isn't required > by the YCBCR extension, but maintenance1 is. Depending upon and interacting are two totally different things. Perhaps the interaction should be called out in a note out something but there's no reason they can't interact. > Anyway, I've submitted a proposal to clarify that the STORAGE usage flag on > multiplanar formats only applies to single-plane VKImageViews. Knowing that > another implementation (nvidia's) also doesn't flag the storage bit for > multiplanar images makes me thing I should word the proposal more strongly > (e.g. if all compatible singleplane representations' formats supports the > STORAGE bit, then it must be set as well for the multiplanar format). I highly doubt that proposal will fly. An implementation advertising STORAGE for a planner format means that you can store to that planner format. Making usage flags for one format actually imply something about views in another format is a fairly bad abuse of the usage flash system. I can't personally speak for the entire working group (thought I am fairly heavily involved with it) but I strongly suspect that using VK_KHR_IMAGE_CREATE_EXTENDED_USAGE_BIT will be their response.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>