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

[Ville Syrjälä]

On Mon, Dec 15, 2014 at 10:19:47PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 12 December 2014 at 18:22, Ville Syrjälä <ville.syrjala at linux.intel.com>
> wrote:
> >
> > On Fri, Dec 12, 2014 at 06:05:49PM +0000, Daniel Stone wrote:
> > > On 12 December 2014 at 18:00, Ville Syrjälä <
> > ville.syrjala at linux.intel.com>
> > > wrote:
> > > > 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.
> > > >
> > >
> > > Anyone who's serious about quality and is also using GL for video, is not
> > > serious about quality. Or accurate timing.
> >
> > You're too hung up on the "GL" there. It doesn't actually matter what
> > you use to render the video when not using the display hardware. The
> > same problem remains.
> 
> 
> Yes, the problem being that sometimes you want to force the hardware to do
> exactly what you want and literally nothing else, and sometimes you don't
> care.
> 
> I posit that a hint-with-optional-force interface is best, because:
>   - if your hint isn't supported, what do you do? fall back to software?
>   - the number of people who care enough to force it is vanishingly small,
> which is partly shown by how:
>   - it matches GL semantics
>   - not a great deal of hardware supports them
> 
> 
> > > > I was more thinking of some global "I want exactly what I said" kind
> > > > of knob. Maybe as a client cap type of thingy.
> > >
> > > I like the idea of keeping it local to the chroma-siting/range hints,
> > > because it makes it far more clear exactly what it affects.
> >
> > You're not thinking wide enough. We would need to add similar hints
> > to pretty much every property.
> 
> 
> Which other properties do we have right now that drivers treat as optional
> hints?

All the src/dst coordinates for one.

> If the answer involves hypothetical new properties, what are they?

Future ones might involve various color adjustment controls, at least if
we want to attempt to make them hardware agnostic.

Color keying properties might be have the same problem. I realize that
treating color keying properties as hints doesn't really make much sense,
but I'm not sure we have any sane alternative since the specific values
you need to plug into the color keying register is rather hardware
specific, and eg. with dst color keying it often depends on the pixel
format of some other plane.

-- 
Ville Syrjälä
Intel OTC