Re: [Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
+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 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 wrote: > > > > > > On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand > > > 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 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
Re: [Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand 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 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
Re: [Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
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 wrote: > > > > On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand 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 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
Re: [Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
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 wrote: > > On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand 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 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
Re: [Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
+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 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
[Mesa-dev] Intel: ABI for DRM format modifiers with multi-planar images
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
