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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 12 December 2014 at 18:00, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
On Fri, Dec 12, 2014 at 05:11:50PM +0000, Daniel Stone wrote:
> 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.

Anyone who's serious about quality and is also using GL for video, is not serious about quality. Or accurate timing.
 
> > 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.

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.

Cheers,
Daniel 
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux