<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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#c12">Comment # 12</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 <a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> Lionel Landwerlin</a> <pre>(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. > > > > > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>