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

[Ville Syrjälä]

On Fri, Dec 12, 2014 at 05:11:50PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 12 December 2014 at 15:30, Ville Syrjälä <ville.syrjala at linux.intel.com>
> wrote:
> >
> > On Fri, Dec 12, 2014 at 03:11:02PM +0000, Daniel Stone wrote:
> > > On 12 December 2014 at 14:56, Ville Syrjälä <
> > ville.syrjala at 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.
> >
> 
> If you're doing it through GL, you've already lost. Either you're doing
> some magic behind the user's back to bind multi-planar dmabuf-EGLImages to
> TEXTURE_2D with RGB sampling, or you're binding to TEXTURE_EXTERNAL_OES,
> which forces you to use linear/nearest filtering. Even if you do use
> TEXTURE_2D binding, the EGLImage import spec does exactly the same as
> what's suggested here, and treats them as hints, which the implementation
> can use or ignore. So far I don't know of any implementation which doesn't
> ignore them.

Well anyone who is serious about quality ought to handle that stuff.
Or at least make sure both GL/whatever and planes ignore the hints in
the same way. So if you GL implementation is lax then you anyway need
to have some driver/hardware specific knowledge to know which way to go
when using the plane path to get matching output.

> 
> FWIW, i965 completely disallows multi-planar EGLImage imports in the first
> place. Mali as shipped on ChromeOS forces you to use TEXTURE_EXTERNAL_OES.
> Soooo ...

Without the strict flag you probably need to patch the kernel too then
to make sure the planes ignore the hint the same way as your GL
implementation. Or vice versa.

> > But for some simpler cases like Xv it would seem perfectly OK to use the
> > less strict rules. Well, unless someone implements Xv in a way that can
> > also transparently switch between display planes and GL/software rendering.
> 
> 
> Well sure, if you absolutely want to ensure it works, you're going to need
> some kind of query. Maybe, if the range/chroma-siting ones were part of a
> bitmask, you could steal the top bit to mark that the hints are actually
> requirements, and to fail if you can't respect the hints.

I was more thinking of some global "I want exactly what I said" kind
of knob. Maybe as a client cap type of thingy.

Another idea I had was to have such a flag in the atomic ioctl. But
it seems impossible to handle that in a sane way unless you require
the caller to specify the entire state every time the ioctl is
called with the flag set.

-- 
Ville Syrjälä
Intel OTC