Re: [PATCH] drm/i915: Tile F plane format support

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

 



On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote:
> > TileF(Tile4 in bspec) format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
> 
> Why we still haven't done the F->tile64 rename?
>
> This is the last chance to fix this before we bake 
> this into the uapi and are stuck with a name that doesn't
> match the spec and will just confuse everyone.

I think you're confusing the formats here.  The bspec uses both terms
"TileF" and "Tile4" for the same format in different places.  There's a
completely different format that's referred to as both "TileS" and
"Tile64" in the bspec that we don't use at the moment.  So tile64
wouldn't be a correct rename, but tile4 could be.

In general Tile4 is much more common in the bspec than TileF is (TileF
terminology is mostly found in the media sections).  And bspec 44917 is
the most authoritative bspec page on the subject, and it refers to it as
Tile4, so I agree that switching over "Tile4" would probably be a good
move.

> 
> > 
...
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index bde5860b3686..d7dc421c6134 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching {
> >  #define I915_TILING_NONE	0
> >  #define I915_TILING_X		1
> >  #define I915_TILING_Y		2
> > -#define I915_TILING_LAST	I915_TILING_Y
> > +#define I915_TILING_F		3
> > +#define I915_TILING_LAST	I915_TILING_F
> 
> fences...

Recognizing TileF/Tile4 separately from TileY is important to code
outside of display as well.  There are blitter instructions that require
different settings for TileY vs Tile4/F so if we drop the tracking of
this as a unique tiling type, it will break the blitting/copying and
some of the upcoming local memory support for Xe_HP-based platforms.


Matt

> 
> >  
> >  #define I915_BIT_6_SWIZZLE_NONE		0
> >  #define I915_BIT_6_SWIZZLE_9		1
> > -- 
> > 2.24.1.485.gad05a3d8e5
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795



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

  Powered by Linux