Hi,
On 12 December 2014 at 18:22, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
> 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? If the answer involves hypothetical new properties, what are they?
Cheers,
Daniel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
