+Chia-I Wu My latest MR there(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11281) has addressed these though I still only enable the single format to be safe (since that's the only one I can thoroughly test and already verified)
On Wed, Jun 9, 2021 at 5:48 PM Chad Versace <c...@kiwitree.net> wrote: > > That's a reasonable plan for now. For LINEAR, X, and Y, the > drmFormatModifierCount is the obvious value for the format. That's enough to > satisfy all the needs of Chrome OS and its zoo of virtual machines. For > simplicity, we can keep VK_FORMAT_FEATURE_DISJOINT_BIT disabled in > drmFormatModifierTilingProperties for multi-planar formats. If we ever need > to squeeze more performance out of shared media images, then we can start > experiments on compressed modifiers and possibly work on defining the ABI > (though, it's always better to have it defined before it's needed, due to > Mesa and kernel release cycles). > > On Wed, Jun 9, 2021, at 16:19, Jason Ekstrand wrote: > > I should have said that the minimal support can be for LINEAR, X-tiled > > and Y-tiled. CCS can and probably should come later. > > > > On Wed, Jun 9, 2021 at 6:14 PM Yiwei Zhang <zzyi...@chromium.org> wrote: > > > > > > On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand <ja...@jlekstrand.net> > > > wrote: > > > > > > > > +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. > > > > > > Hi, > > > > > > I have sent a > > > MR(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11281) > > > to add the minimal multi-planar format support with drm format > > > modifier, so that Venus Android AHB extension layered on top of ANV > > > VK_EXT_image_drm_format_modifier implementation can pass all the > > > interop graphics cts for camera and media. > > > > > > I'd be interested to follow up about the stable ABI for this to expand > > > multi-planar support there. > > > > > > Best, > > > Yiwei > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
