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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxx>
> > Cc: Matt Roper <matthew.d.roper@xxxxxxxxx>
> > Cc: Nanley G Chery <nanley.g.chery@xxxxxxxxx>
> > Cc: Jason Ekstrand <jason@xxxxxxxxxxxxxx>
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx>
> > Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
> > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx>
> > ---
> >  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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux