<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c18">Comment # 18</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 <span class="vcard"><a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> <span class="fn">Lionel Landwerlin</span></a>
</span></b>
        <pre>(In reply to atomnuker from <a href="show_bug.cgi?id=105496#c17">comment #17</a>)
<span class="quote">> (In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c16">comment #16</a>)
> > (In reply to atomnuker from <a href="show_bug.cgi?id=105496#c15">comment #15</a>)
> > > (In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c14">comment #14</a>)
> > > > 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.</span >

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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>