[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 21:37:38 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=105496

--- Comment #16 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
(In reply to atomnuker from comment #15)
> (In reply to Lionel Landwerlin from comment #14)
> > The ffmpeg repo I built locally had the image below bound to a G8_B8_R8
> > image.
> Yes, the one before I pushed. I only used 1 plane in order to test easily
> without modifying lots of code.
>  
> > layout (set = 0, binding = 0, rgba8) uniform readonly image2D input_img;
> > 
> > But somehow it should contain all the planes?
> Like I said, no, just one: the one with the aspect (plane) you chose via the
> VkImageView.
> 
> To illustrate:
> VkImage (VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR) -> create VkImageView
> (VK_FORMAT_R8_UNORM and aspect VK_IMAGE_ASPECT_PLANE_0_BIT_KHR) -> bind to
> descriptor which describes a storage image inside the shader ->
> imageLoad(input_img, vec2(0)).r will output the pixel of the image at
> location x=0, y=0.

We can't do that, because enabling storage support on a
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR image means we would need to support
that storage on that entire format too (not just on one plane).

> 
> To have access to all planes you need to create separate imageviews and bind
> them to different images inside the shader, like:
> > layout (set = 0, binding = 0, rgba8) uniform readonly image2D input_img[3];
> > layout (set = 0, binding = 1, rgba8) uniform writeonly image2D output_img[3];
> 
> When you do a read into one of the source images you'll get the pixel value
> inside the .r component of the resulting vec4. The rest of the components
> contain 0.0f, as expected when the format contains 1 component.

-- 
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/3196b116/attachment.html>


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