Xgl/Xegl future?

[Matthias Hopf]

On Aug 24, 05 10:59:28 -0600, Brian Paul wrote:
> >>>>But an OpenGL based Xserver can use the graphics hardware for scaling
> >>>>and color conversion of XV surfaces (that's what I've been working on).
> >>>
> >>>So can a GL based compositing manager.
> >>
> >>No. Not with current Xservers. No way to get YUV / YUY2 data in native
> >>format. This isn't easily possible to implement, either, as the PutImage
> >>call does not have to completely fill a Window, and RGB data can be
> >>drawn over it afterwards as well.
> >
> >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.

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).

Therefore you cannot use these surfaces for compositing when they are
not already converted.

> Just FYI, there's the GL_MESA_ycbcr_texture extension that let's you 
> pass a YCbCr texture image to GL.  The YCbCr -> RGB conversion is done 
> by the hardware when the texture is applied to a polygon.

I checked all three (!) available ycbcr extensions, non of them fit.
E.g. I have to be able to do planar YUV to RGB conversion, all
extensions that are there right now are only able to do process
interleaved YUV (i.e. YUY2) data.

> Arbitrary color-space conversion can also be done with fragment 
> programs nowadays.

That's what I've always be talking about. It is working in the xine
OpenGL output plugin, and I have shown a demo of this conversion stuff
working inside Xgl (using the XV extension as API) on the LinuxTag in
Karlsruhe.

Unfortunately, Xglx has changed too much internally, so it isn't working
at the very moment. But I'll be working on it shortly.

> Using the GL hardware for that kind of stuff seems pretty interesting.

:) It is.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de