[PATCH 2/3] drm/i915: Add format modifiers for Intel

Fri Jan 13 09:35:56 UTC 2017

On Thu, Jan 12, 2017 at 10:56:17AM -0800, Ben Widawsky wrote:
> On 17-01-12 20:32:07, Ville Syrjälä wrote:
> >On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
> >> On 17-01-12 12:51:20, Ville Syrjälä wrote:
> >> >On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> >> >> This was based on a patch originally by Kristian. It has been modified
> >> >> pretty heavily to use the new callbacks from the previous patch.
> >> >>
> >> >> Cc: Kristian H. Kristensen <hoegsberg at gmail.com>
> >> >> Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> >> >> ---
> >> >>  drivers/gpu/drm/i915/intel_display.c | 109 ++++++++++++++++++++++++++++++++++-
> >> >>  drivers/gpu/drm/i915/intel_sprite.c  |  33 ++++++++++-
> >> >>  2 files changed, 137 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> >> index 8715b1083d1d..26f3a911b999 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> >> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> >> >>  	DRM_FORMAT_XRGB8888,
> >> >>  };
> >> >>
> >> >> +static const uint64_t i8xx_format_modifiers[] = {
> >> >> +	I915_FORMAT_MOD_X_TILED,
> >> >
> >> >Did we want to list the linear modifier in these as well?
> >> >
> >>
> >> Yeah. My initial response was no, but yes. We should. I was using
> >> DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be defined
> >> in the array.
> >>
> >> >> +	DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >>  /* Primary plane formats for gen >= 4 */
> >> >>  static const uint32_t i965_primary_formats[] = {
> >> >>  	DRM_FORMAT_C8,
> >> >> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> >> >>  	DRM_FORMAT_XBGR2101010,
> >> >>  };
> >> >>
> >> >> +static const uint64_t i965_format_modifiers[] = {
> >> >> +	I915_FORMAT_MOD_X_TILED,
> >> >> +	DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >
> >> >We could just share the i8xx array. The name of the array should perhaps
> >> >be i9xx_format_modifiers[] in that case. That's sort of the naming
> >> >convention we've been left with for things that apply to more or less
> >> >all the platforms.
> >> >
> >>
> >> Got it thanks. This is a relic from Kristian's original patch which tied the
> >> modifiers to the formats in place. It made more sense there to have a separate
> >> i8xx
> >>
> >> >> +
> >> >>  static const uint32_t skl_primary_formats[] = {
> >> >>  	DRM_FORMAT_C8,
> >> >>  	DRM_FORMAT_RGB565,
> >> >> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> >> >>  	DRM_FORMAT_VYUY,
> >> >>  };
> >> >>
> >> >> +static const uint64_t skl_format_modifiers[] = {
> >> >> +	I915_FORMAT_MOD_Y_TILED,
> >> >
> >> >Yf missing? and linear
> >> >
> >>
> >> Yes, thanks. I'm kind of scared to add Yf to be honest :P
> >>
> >> >> +	I915_FORMAT_MOD_X_TILED,
> >> >> +	DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >>  /* Cursor formats */
> >> >>  static const uint32_t intel_cursor_formats[] = {
> >> >>  	DRM_FORMAT_ARGB8888,
> >> >> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
> >> >>  	kfree(to_intel_plane(plane));
> >> >>  }
> >> >>
> >> >> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> +	if (modifier == DRM_FORMAT_MOD_NONE)
> >> >> +		return true;
> >> >> +
> >> >> +	switch (format) {
> >> >> +	case DRM_FORMAT_C8:
> >> >> +	case DRM_FORMAT_RGB565:
> >> >> +	case DRM_FORMAT_XRGB1555:
> >> >> +	case DRM_FORMAT_XRGB8888:
> >> >> +		return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> +	default:
> >> >> +		return false;
> >> >> +	}
> >> >> +}
> >> >> +
> >> >> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> +	switch (format) {
> >> >> +	case DRM_FORMAT_C8:
> >> >> +	case DRM_FORMAT_RGB565:
> >> >> +	case DRM_FORMAT_XRGB8888:
> >> >> +	case DRM_FORMAT_XBGR8888:
> >> >> +	case DRM_FORMAT_XRGB2101010:
> >> >> +	case DRM_FORMAT_XBGR2101010:
> >> >> +		return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> +	default:
> >> >> +		return false;
> >> >> +	}
> >> >> +}
> >> >
> >> >Hmm. There should be no format vs. tiling restrictions on these
> >> >platforms, so presumably a simple "return true" should cover it all.
> >> >That does perhaps remove the usefulness of these functions for
> >> >verifying that the format or modifier is supported at all
> >>
> >> One of the reasons for changing to this current format-modifier lookup at all
> >> was Kristian's approach was considered fragile. If for whatever reason formats
> >> are added, or removed, we'll catch it here. Also, it maybe let's us do something
> >> on cursor plane at some point (I don't actually know). So yeah, we can return
> >> true, but I like that it's spelled out explicitly. Makes it easy to compare it
> >> to the docs as well to make sure our code is correct.
> >>
> >> The benefit is of course I can combine i965_mod_supported() with
> >> i8xx_mod_supported()
> >>
> >> I'm honestly fine with changing it as well, I just don't see a huge reason to
> >> change it since I've already typed it up. I'll leave it to you.
> >
> >Feel free to keep it. We can always change it later if it becomes too much
> >work to maintain the duplicated format lists (the function and the array).
> >Not that I really expect these lists to be all that volatile.
> >
> >>
> >> [ ] Yes, change it.
> >> [ ] No, leave it.
> >>
> >> >but I've been thinking that addfb should perhaps just iterate through the
> >> >format and modifier lists for every plane. Would avoid having to effectively
> >> >maintain the same lists in multiple places.
> >> >
> >>
> >> I don't quite follow this. Can you elaborate?
> >
> >I was just thinking that instead of addfb passing in an unverified format
> >to the driver's .fb_create() hook, it could first go through the format
> >lists of each plane, and make sure at least one of them supports the
> >requested format. That way we could eliminate that fragile pixel_format
> >switch statement from intel_framebuffer_init().
> >
> >But if you plan on making the .format_mod_supported() hooks 100%
> >strict, then we could use that instead. Would avoid having to walk
> >the format lists of every plane at least.
> >
> 
> Let's keep it the way things are for now, mostly because I'm lazy and this
> works.
> 
> >>
> >> >> +
> >> >> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> +	switch (format) {
> >> >> +	case DRM_FORMAT_C8:
> >> >> +	case DRM_FORMAT_RGB565:
> >> >> +	case DRM_FORMAT_XRGB8888:
> >> >> +	case DRM_FORMAT_XBGR8888:
> >> >> +	case DRM_FORMAT_ARGB8888:
> >> >> +	case DRM_FORMAT_ABGR8888:
> >> >> +		return modifier == I915_FORMAT_MOD_Y_TILED ||
> >> >> +			modifier == I915_FORMAT_MOD_X_TILED;
> >> >> +	case DRM_FORMAT_XRGB2101010:
> >> >> +	case DRM_FORMAT_XBGR2101010:
> >> >> +		return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> +	case DRM_FORMAT_YUYV:
> >> >> +	case DRM_FORMAT_YVYU:
> >> >> +	case DRM_FORMAT_UYVY:
> >> >> +	case DRM_FORMAT_VYUY:
> >> >
> >> >IIRC on SKL the only restrictions should be that CCS modifiers are
> >> >limited to 8:8:8:8 formats only. Other modifiers should work
> >> >with any format.
> >> >
> >>
> >> This restriction was copied from Kristian's patch. I just checked the docs and
> >> you are correct. So this needs Yf modifier too. (Aside from CCS, rotation is the
> >> one case: x-tiled 1010102 isn't supported).
> >
> >I can't see any extra restrictions for 10bpc formats.
> >
> >The only exception I see for 0/180 degree rotation is FP16 not being
> >supported with Yf. And since we don't actually expose FP16 we don't have
> >to worry about it. So apart from the CCS+8:8:8:8 cases all other
> >format+modifier combos should be perfectly fine AFAICS.
> >
> >My information was gleaned from the "plane capability" table in the
> >spec, but I wasn't able to immediately spot any additional restriction
> >in the PLANE_CTL register description either.
> >
> 
> Sorry for making you verify that, I think you are correct and I'm misreading the
> table. I was just looking at the specific columns: Linear and X-tiled 90/270
> rotation aren't supported with 1010102, but they aren't supported with any other
> surface format either.
> 
> However, looking again now, it looks like DRM_FORMAT_C8 doesn't support Yf.

Hmm. Indeed. That might be related to 
https://lists.freedesktop.org/archives/intel-gfx/2017-January/116027.html

My observation on actual hardware was that Yf tile width didn't match
what we were expecting with 8bpp and 64bpp formats. It did actually work
otherwise though. Possibly someone else noticed the same problem and
"removed" Yf support for these formats. Either that or it was like this
all the time and we just didn't notice. Although I'm still not 100% sure
what the Yf tile width should be since the spec is superbly confusing on
this topic.

If we reject Yf on 8bpp, then I can probably just drop that patch of
mine, and someone will get to revisit it when/if we officially get
8bpp/64bpp Yf support.

-- 
Ville Syrjälä
Intel OTC