<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#c13">Comment # 13</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:atomnuker@gmail.com" title="atomnuker@gmail.com">atomnuker@gmail.com</a>
</span></b>
<pre>(In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c12">comment #12</a>)
<span class="quote">> (In reply to atomnuker from <a href="show_bug.cgi?id=105496#c11">comment #11</a>)
> > (In reply to Lionel Landwerlin from <a href="show_bug.cgi?id=105496#c10">comment #10</a>)
> > > (In reply to atomnuker from <a href="show_bug.cgi?id=105496#c9">comment #9</a>)
> > > > (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.
> > >
> > > 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.
> > Yes you can. Its listed right there in the compatible formats. Check out the
> > earlier link I posted. 422 images support VkImageView of R8 for the luma
> > plane and R8G8 for the chroma planes (so you get vec2() for the chroma plane
> > of such images). In my use case I need to be able to do this for all YUV
> > images, since otherwise they'd be pretty much useless. And you can do that
> > with all YUV images like it says in the spec.</span >
I should correct myself, this is for NV12. For 422 you use the same procedure
as 420 but with the image resolution being halved horizontally.
<span class="quote">> >
> >
> > >
> > > 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);
>
> If you swizzle the result here, I'm pretty sure you won't get what you
> expect.
> Hopefully that convinces you that this isn't supported.</span >
Well of course it won't work, this copies 1 plane only. For multiplane images I
make both the output images and input images arrays and I iterate over them.
The result vec4 only contains 1 pixel value in the .r member.
Like the spec says, creating a single plane imageview from a multiplane format
exposes 1 plane and 1 plane only.
I have pushed a new version to the same repository which works for 420, 422 and
444 images. Tested. It also works for NV12 images with minimal modifications
(iterating over 2 planes instead of 3 and with different format on the second
plane).
If you have nothing more to argue about then I propose we end this conversation
and instead focus on fixing the flags.</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>