[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 #12 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
(In reply to atomnuker from comment #11)
> (In reply to Lionel Landwerlin from comment #10)
> > (In reply to atomnuker from comment #9)
> > > (In reply to Lionel Landwerlin from comment #8)
> > > > 
> > > > 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.
> 
> 
> > 
> > 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.


> > }
> > 
> > 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.
> I don't need to sample for this particular case. Sampling ought to be slower
> as well. I just need to fetch individual pixels without interpolation. And
> like I said, this works as long as you disrespect what the driver currently
> reports and flag the STORAGE bit when creating the image. So its a matter of
> marking it as supported.

-- 
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/20180316/2998a48b/attachment.html>