+Nanley We've not defined those yet. We had some internal talks a couple years ago. The rough idea we had at the time was to define a modifier for those cases which put the CCS after each main surface at some fixed calculation offset based on width, height, and stride. Then the one modifier would apply independently to the three different planes.
--Jason On Wed, Jun 9, 2021 at 2:11 PM Chad Versace <c...@kiwitree.net> wrote: > > The Problem: For a given 3-tuple (multi-planar format, DRM format modifier, > chipset), we need Intel ABI that decides (a) the value of > VkDrmFormatModifierPropertiesEXT::drmFormatModifierPlaneCount and (b) the > content of each "modifier" plane. > > For example, suppose drmFormatModifierPlaneCount is 2 for > (VK_FORMAT_G8_B8R8_2PLANE_420_UNORM, INTEL_FORMAT_MOD_FOO). Is the layout > (plane1=g8, plane2=b8r8); or is it (plane1=g8_b8r8, plane2=aux)? The second > choice isn't crazy; iirc, some non-Intel hardware (sorry, NDA) uses only 2 > modifier planes for color-compressed 3-planar formats, with (plane1=r8_g8_b8, > plane2=aux). > > I'm asking because Yiwei (cc'd) has begun implementing limited support for > multi-planar formats in Anvil in order to pass the Android CTS. To support > more media formats (for imminent Chrome OS projects and future vanilla Linux > stuff too), we need to decide on some ABI. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
