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 99624
To read all comments associated with this story, please click here.
Inaccurate
by siki_miki on Mon 27th Feb 2006 11:25 UTC
siki_miki
Member since:
2006-01-17

Article states that direct rendering is possible with AIGLX, while it is much harder to do with XGL.

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)

Same improvements to driver frameworks are needed to get this working for both 'solutions' (e.g GPU memory management and scheduling). Also, Extensions are needed to have framebuffer of direct GL program redirected to offscreen memory, without program knowing it, and available (shared) for compositing (not sure if texture_from_pixmap suffices). In fullscreen it is however easier because you suspend your XGL/AIGLX and let the program have exclusive access to 3D interface.

Reply Score: 2

RE: Inaccurate
by somebody on Mon 27th Feb 2006 17:49 in reply to "Inaccurate"
somebody Member since:
2005-07-07

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:
2006-01-17

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