<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#c10">Comment # 10</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#c9">comment #9</a>)
<span class="quote">> (In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c8">comment #8</a>)
> > 
> > We don't support storage on multiplanar formats indeed.
> > 
> > But R8_UNORM should be reported as supporting storage.
> > 

> The latter (and RGBA) does indeed but since you're attaching the original
> multiplane image to the descriptor (albeit indirectly though a derived
> imageview) its that VkFormat that needs to have STORAGE bit supported. It
> already supports the SAMPLE bit (needed for YUV->RGB converting samplers) so
> I guess its just a matter of flagging STORAGE as well.</span >

It's more or less luck that it works for this particular couple of formats.
For something like G8B8G8R8_422_UNORM the hardware really can't do it.
So I don't think we want to enable storage on anything ycbcr.


Rereading the shader from your repo : 

#version 460

layout (local_size_x = 16, local_size_y = 16) in;
layout (set = 0, binding = 0, rgba8) uniform readonly image2D input_img;
layout (set = 0, binding = 1, rgba8) uniform writeonly image2D output_img;

void main()
{
    vec4 result = imageLoad(input_img, ivec2(gl_GlobalInvocationID.xy));
    imageStore(output_img, ivec2(gl_GlobalInvocationID.xy), result);
}

I'm not sure I understand what is going on here. Is that you're reading from
one texture and writing to the same one?

Regardless of what texture you access, I think what would work is to have a
sampler for the ycbcr texture as input, then you can store to anything that
supports storage.</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>