Linked by Eugenia Loli on Mon 27th Feb 2006 07:10 UTC, submitted by fsmdave
X11, Window Managers 3D graphics on X11: XGL vs AIGLX. This article delves into the inner workings of XGL and AIGLX. It shows that there are many similarities between these two competing/co-operating "rivals" and plenty of room for growth.
Thread beginning with comment 99731
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Inaccurate
by somebody on Mon 27th Feb 2006 17:49 UTC in reply to "Inaccurate"
Member since:

I doubt that this is true. If you run compositing manager and direct GL program at the same time, both xserver and that program access libGL and 3D driver directly at the same time. This is what should happen in both XGL and AIGLX scenario. (If you turn off AIGLX-based compositing, you end up with traditional Xserver, where you can run direct GL progs currently)

Nope. XGL does have this problem, AIGLX not. Difference lies in question where rendering solution resides.

XGL is a separate server and can't take control over direct GL program.
AIGLX is inside of XServer, and when enabled AIGLX is controlling the GL (even direct GL softwares talk to him without even knowing it). Nothing simpler than to redirect ones commands if needed. This was the whole reason for AIGLX, or at least the most important one.

Reply Parent Score: 3

RE[2]: Inaccurate
by siki_miki on Mon 27th Feb 2006 22:18 in reply to "RE: Inaccurate"
siki_miki Member since:

AIGLX can't redirect directGL programs, i.e. their GL API calls. It(=compositing manager on AIGLX) can only use dedicated OpenGL extension to redirect their screen output to offscreen buffer and be able to read it so it can be composited with the rest of the desktop. So it requires special driver support, in form of GL extension(s) (I'm not sure if this yet exists). There is no reason Xgl couldn't in the same manner allow that program to access libGL and to do it's direct rendering, while redirecting output using described mechanism (this is analogous to XComposite extension, only it happens in driver instead of X Server).

Big problem here is memory management. When both compositing manager and another app use video memory, it soon will become too fragmented, thus not too usable for new allocations. Some GPU scheduling might also come at hand if you want smooth desktop experience while something else is choking GPU.

AIGLX-based compositing manager, in the end, redirects all xserver windows to offscreen buffers (that's what XComposite is for) and uses acelerated GL calls to manipulate them and compose final screen. This is more similar to XGL way than many people think.

Edited 2006-02-27 22:20

Reply Parent Score: 1

RE[3]: Inaccurate
by somebody on Mon 27th Feb 2006 22:35 in reply to "RE[2]: Inaccurate"
somebody Member since:

Yep, you're correct here. I'm gonna try to correct my statement as I wanted to say it originaly in my head.

It seems to me that what is more natural to one, is more hackish for another. AIGLX can just do the same thing as XGL, just politicaly more correct.

Just wondering since you mention scheduling requests. Aren't XFixes and XDamage bound to become part of complete picture in the end? As I recall they haven't been really active yet. Those two are intended for this kind of work, aren't they?

Edited 2006-02-27 22:42

Reply Parent Score: 1