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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Mar 17 01:18:39 UTC 2018


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

--- Comment #18 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
(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.

-- 
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/5a176e02/attachment.html>


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