Re: [RFC] drm: add support for tiled/compressed/etc modifier in addfb2

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC] drm: add support for tiled/compressed/etc modifier in addfb2
Date: Fri, 12 Dec 2014 18:14:17 +0200	[thread overview]
Message-ID: <20141212161417.GU10649@intel.com> (raw)
In-Reply-To: <CAF6AEGugbT8fRnGRfhgydm6i7Xf5Py5KSyTmkZBkb5sk6u+GWQ@mail.gmail.com>

On Fri, Dec 12, 2014 at 11:00:29AM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 10:30 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >>
> >> Having them separated is still kinda nice though, for the same rationale as
> >> the EGLImage import extension having them as hints. If your hardware
> >> doesn't support the tiling/compression format you use, then you're going to
> >> be showing absolute garbage. But if it doesn't support your exact
> >> chroma-siting or YUV range request, it'll still be totally viewable, just
> >> not entirely perfect. So I don't see the logic in failing these.
> >
> > Well, it will look nasty when switching between GL and display
> > composition the GL path does the right thing an display path doesn't/
> > And we already have that problem with the fuzzy alignment/scaling
> > restriction stuff. So I think we will want some kind of strict flag
> > somewhere to allow the user to specify that they'd rather fail the whole
> > thing and fall back to GL rather than annoy the user.
> 
> 
> another argument in favor of plane properties, I think.  This way
> userspace can query what is actually possibly and we don't implicitly
> give userspace the idea that display hw can handle something that it
> doesn't..

Well, we don't have properties to describe a lot of the limitations. I'm
not sure we want to add tons of read-only properties for that. And as
stated, sometimes the limitations depend on other properties/pixel
format/etc. so seems rather hard to describe in a sane way that would
actually be useful to userspace.

One idea that came up again just yesterday would be to have the kernel
assign the planes on behalf of userspace. But that would then mean we
need some kind of virtual plane layer on top so that the virtual plane
state gets tracked correctly, or userspace would need to pass in the
entire state for every display update. Also soon it may start to look
like we're implementing some kind of compositor in the kernel. Another
other approach might be to implement this plane assignment stuff in
libdrm and duplicate some hw specific knowledge there.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel