Xgl and direct rendering

[Owen Taylor]

On Mon, 2006-02-27 at 18:53 +0100, Roland Scheidegger wrote:
> R300 pixel shaders should work just fine, though I don't have such a 
> card to test.
> Both R100 and R200 (and r300, i8/9xx,...) however support yuv textures, 
> and the code should probably be modified to take advantage of them when 
> available (not very well standardized unfortunately, but 
> GL_MESA_ycbcr_texture should fit the bill). (Note that they are broken 
> on rv250 apparently, however, it should be possible to fix them up with 
> a quite simple "fragment program" as at least the component ordering 
> seems to be correct).
> I think not being able to use the hw overlay is the biggest drawback of 
> Xgl, it makes it utterly useless for quite a few people (think HTPC with 
> unichromes for instance). 

(If anybody else was confused HTPC == Home Theater PC... took me a while
before I figured it out.)

> Maybe that capability should somehow be added 
> back, even though it will not integrate into the nice 3d environment 
> well and might cause ugly looking artifacts (as you can't transform it, 
> it will always be a rectangle).
> Sure, hw overlay has its limitations (usually only 1 per gpu, in case of 
> the radeons you can't have it on both screens even with mergedfb etc.) 
> but it usually gets the job done very well.

This should be pretty easy with the AIGLX architecture, since there is
only one X server involved; it's pretty much just a matter of figuring
out the application <=> compositing manager protocol to get things
to appear right for the user.

(You don't want the controls around your video player to get transformed
and have your video stream stay as an untransformed rectangle or
something...)

It may be that the only interesting case is full-screen video, which
is the easiest case to design, since the compositing manager basically
just has to get out of the way.

This "get-out-of-the-way-I'm-going-fullscreen" protocol is also needed
for fullscreen 3D games with direct rendering.

It's going to be harder with the Xgl approach, since you have an 
intermediate server between the client and the X server that supports
the video overlay. But for the full-screen case, maybe the simple
thing to do is to just have the video app have a second connection to
the underlying X server, so "going fullscreen" is just lowering the
Xgl server and raising the window with the full-screen video.

With Xegl it gets even harder ... you'd need a GL extension with similar
capabilities to Xvideo or something like that.

Regards,
						Owen