[Bug 105496] Using a single-plane imageview from a multi-plane image is broken

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Mar 19 00:40:16 UTC 2018


--- Comment #26 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to atomnuker from comment #24)
> (In reply to Lionel Landwerlin from comment #23)
> > Digging through the khronos gitlab, it seems the extended flags was added
> > for another purpose :
> > https://gitlab.khronos.org/vulkan/vulkan/merge_requests/1896
> > 
> > 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

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.

You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180319/7d412ff5/attachment.html>

More information about the intel-3d-bugs mailing list