eta at lclark.edu
Sun Aug 28 14:08:42 PDT 2005
On Fri, 2005-08-26 at 13:05 +0200, Matthias Hopf wrote:
> On Aug 25, 05 23:05:04 -0400, Michel Dänzer wrote:
> > On Thu, 2005-08-25 at 18:30 +0200, Matthias Hopf wrote:
> > > On Aug 24, 05 10:59:28 -0600, Brian Paul wrote:
> > > > >
> > > > >Obviously a GL compositing manager wouldn't be doing the YUV to RGB
> > > > >conversion, since the compositing manager is at the wrong level. It
> > > > >should be done in the XV handler of the driver in the DDX. It's been
> > > > >done in several KAA (aka EXA) drivers before, using the graphics
> > > > >hardware for scaling.
> So we were talking about the mehanisms that were used before (XV handler
> of the current drivers).
Well, nearly every driver currently in X.Org uses the overlay scaler.
MGA is the exception I know of, and that's just an option. I would like
to see us use the texture scaler to get the job done where possible,
since it lets us play nice with composite and lets you have multiple
hardware-accelerated YUV videos put on the screen at a time.
> > > Yes, but as soon as we want an abstraction layer (in this case OpenGL),
> > > this isn't easily accessible, as several hardware vendors chose to not
> > > convert YUV to RGB on PutImage, but during scanout (using color keying
> > > for selecting the YUV framebuffer).
> > We're not talking about overlays (which will be little use with
> > compositing) but about using the 3D engine to do the colourspace
> > conversion and scaling.
> I was talking about that there is no common interface for YUV to RGB
> conversion using the graphics hardware. Thus we should do this with
> pixel shader, which *is* a common interface that is capable of doing
> this. We can have other implementations if the hardware doesn't support
> pixel shader, but this will be our first try.
Very little of the hardware that we support supports pixel shaders. I
mean, we could do this with r200 probably and r300, maybe i915? (I don't
Lots more of the hardware that we support can support YUV conversion
using the texture hardware exposed using the MESA extension that Brian
mentioned, and it's simple to write the support for it.
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the xorg