[Intel-gfx] [PATCH 01/15] drm/framebuffer: Format modifier for Intel Gen-12 render compression

Imre Deak imre.deak at intel.com
Thu Dec 19 23:30:53 UTC 2019


On Thu, Dec 19, 2019 at 01:03:52PM -0800, Matt Roper wrote:
> On Wed, Dec 18, 2019 at 06:10:51PM +0200, Imre Deak wrote:
> > From: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
> > 
> > Gen-12 has a new compression format, add a new modifier to indicate that.
> 
> There's been some recent hallway chat about this, but it might be worth
> naming this "TGL" rather then "GEN12" and using a fresh modifier even if
> future gen12+ platforms seemingly have the same general CCS layout and
> programming model.  Using the same modifier between multiple platforms
> implies that the data format truly is compatible between them and that
> one platform can consume the surfaces generated by another (even if you
> can't do direct sharing via dma_buf, you could theoretically copy buffer
> contents over the network, save/restore buffers from disk, etc.).  Even
> if things look identical at the bspec level, there's no guarantee that
> the hardware guys won't tweak the underlying compression algorithm
> between platforms in a way that makes the buffers generated by one GPU
> incompatible with a different platform.
> 
> In fact we've already seen one instance of this type of incompatibility
> --- EHL/JSL's GT uses a very slightly different packing format than ICL
> did.  In that case there was a chicken register we could use to make the
> EHL GT use the ICL-style packing (and we had to set this bit anyway for
> the display controller to be able to consume GT-rendered buffers).  But
> going forward I think we probably want to use per-platform modifiers
> rather than per-generation modifiers by default.

Okay, however, the possibility to share the buffers between GPUs
(without having to decompress/recompress) is an important feature imo,
so I wouldn't be surprised if HW would be designed with this in mind.
Some kind of architecture document proposed actually these modifier
names, not sure if the authors of that didn't think about buffer
sharing.

Can't we assume that the design would be sensible and call the format
that is shareable at least among GEN12 platforms GEN12? I think we could
use a new modifier name for a platform generating an incompatible
format. I agree that we should make sure the buffers are truly shareable
before allowing to share modifier names.

--Imre

> 
> Matt
> 
> > 
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Cc: Matt Roper <matthew.d.roper at intel.com>
> > Cc: Nanley G Chery <nanley.g.chery at intel.com>
> > Cc: Jason Ekstrand <jason at jlekstrand.net>
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
> > Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
> > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > ---
> >  include/uapi/drm/drm_fourcc.h | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8caaaf7ff91b..5ba481f49931 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -410,6 +410,17 @@ extern "C" {
> >  #define I915_FORMAT_MOD_Y_TILED_CCS	fourcc_mod_code(INTEL, 4)
> >  #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
> >  
> > +/*
> > + * Intel color control surfaces (CCS) for Gen-12 render compression.
> > + *
> > + * The main surface is Y-tiled and at plane index 0, the CCS is linear and
> > + * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
> > + * main surface. In other words, 4 bits in CCS map to a main surface cache
> > + * line pair. The main surface pitch is required to be a multiple of four
> > + * Y-tile widths.
> > + */
> > +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
> > +
> >  /*
> >   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> >   *
> > -- 
> > 2.22.0
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795


More information about the Intel-gfx mailing list