<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#c11">Comment # 11</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:atomnuker@gmail.com" title="atomnuker@gmail.com">atomnuker@gmail.com</a> <pre>(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); > } > > 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>