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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Mar 16 17:31:49 UTC 2018


--- Comment #11 from atomnuker at gmail.com ---
(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);
> }
> 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/24645a19/attachment-0001.html>

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