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

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105496

--- Comment #19 from atomnuker at gmail.com ---
(In reply to Lionel Landwerlin from comment #18)
> (In reply to atomnuker from comment #17)
> > (In reply to Lionel Landwerlin from comment #16)
> > > (In reply to atomnuker from comment #15)
> > > > (In reply to Lionel Landwerlin from comment #14)
> > > > > The ffmpeg repo I built locally had the image below bound to a G8_B8_R8
> > > > > image.
> > > > Yes, the one before I pushed. I only used 1 plane in order to test easily
> > > > without modifying lots of code.
> > > >  
> > > > > layout (set = 0, binding = 0, rgba8) uniform readonly image2D input_img;
> > > > > 
> > > > > But somehow it should contain all the planes?
> > > > Like I said, no, just one: the one with the aspect (plane) you chose via the
> > > > VkImageView.
> > > > 
> > > > To illustrate:
> > > > VkImage (VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR) -> create VkImageView
> > > > (VK_FORMAT_R8_UNORM and aspect VK_IMAGE_ASPECT_PLANE_0_BIT_KHR) -> bind to
> > > > descriptor which describes a storage image inside the shader ->
> > > > imageLoad(input_img, vec2(0)).r will output the pixel of the image at
> > > > location x=0, y=0.
> > > 
> > > We can't do that, because enabling storage support on a
> > > VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR image means we would need to support
> > > that storage on that entire format too (not just on one plane).
> > 
> > We must: the spec explicitly states that API users MUST check if the
> > VkFormat supports the STORAGE bit for the current tiling mode. If its not
> > flagged, then the STORAGE usage bit MUST NOT be present when creating the
> > image. If the storage bit isn't enabled then any VkImageViews created from
> > the VkImage will not support storage, even if the VkFormat of the
> > VkImageView supports the STORAGE bit for the particular tiling mode.
> > 
> > Hence, we must flag the STORAGE bit for the VkFormat, even if users can't
> > directly access all the planes via a single image2D. I can propose that the
> > spec is changed such that it mentions this, if it makes you feel more
> > comfortable. But to move forward and enable users to do _actual_ useful
> > things to multiplane images (and not take chances by flagging usages
> > reported to be unsupported) we should flag this.
> 
> If you get the spec changed, I'll be happy to add the storage bit on
> multi-planar formats.
> As it stands though, supporting storage on multi-planar (in all possible
> cases) is a few changes not really worth making since you can avoid it with
> just an additional VkImage.

Which is an ugly hack which relies that the memory bound to both images is
properly aligned, has the same tiling and is otherwise idential in all
respects. Its awful. I don't know how you can even propose this to be a valid
workaround. You do realize that you're contradicting and rejecting a part of
the specifications? And until today I don't think you had even heard of this
despite stating that you wrote a part of it.
I'd like to have another person's opinion on this, preferably someone who
actually reads the spec.

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