AIGLX and XGL
In my previous post about Compiz and Emerald I explained how I installed AIGLX to enable hardware accelerated rendering in X Windows, a requirement for the fancy window effects seen all over the web lately. As a response to that post hints at there is another option – XGL.
I opted for using AIGLX since XGL is no longer maintained, and AIGLX is therefore the default choice in Ubutnu. Though I didn’t look into the reason behind the disappearance of XGL when installing Xubuntu, my curiosity was this time triggered when asked about the difference between the two.
On the surface both XGL and AIGLX provide the same functionality. They bridge the gap between the X Window System and hardware accelerated 3D graphics. Originally the X Window System was designed to show 2D graphics, since that was the only thing available at the time. As computers evolved there came a need to support 3D graphics.
To begin with X supported this through the Mesa library. The Mesa library worked as a wrapper around the OpenGL graphics library. It exposed parts of the OpenGL API, and then translated the calls to X calls which was sent to the X Window System using its’ special X protocol. This allowed 3D graphics to be shown, but it didn’t get any benefit from 3D hardware.
Another way to access the OpenGL library was also created. It used X’s extension mechanism to create an extension that intercepted OpenGL calls and passed them along to the computer’s graphic driver. This method was called ‘GLX’, and the mechanism was called ‘Indirect Rendering’ (indirect since the calls passed through X before going to the hardware).
As time passes the demand for fancy effects in window managers increased. The current options of GLX and Mesa wasn’t enough to still this demand, so two other options emerged: XGL (X-to-OpenGL) and AIGLX (Accelerated Indirect GLX). Both had the same overall goal; making 3D acceleration possible in window managers using the communication protocol already established by the X Window System.
XGL went about its’ business by replacing the underlying X server with a new server that supported accelerated OpenGL rendering. Due to the major changes in the underlying architecture this approach required hardware vendors need to support a special API. Currently very few (if any) cards support this, so the development is currently stalled. Before the project stalled they did release a development server called XGLX, but instead of replacing the original X server it wrapped it to supply the functionality required for testing hardware and software. A second server, XEGL, was also in development when the project stalled, but its’ future seems uncertain now.
On the other hand AIGLX decided to leverage the extension options already present in the X Window System. The window manager will in this case send the information to a special OpenGL API, supplied by AIGLX, which translates the commands into GLX commands. These commands are then passed along to the hardware for rendering, before the result is passed back to the X Window System and finally displayed to the user. Some of this back-and-forth passage of information can be avoided if pixmap manipulation commands are enabled in the X-server, but the general idea behind AIGLX remains the same.
After having done this research into the history and nature of AIGLX and XGL I hope that XGL manages to get the hardware support required to continue development. Its’ approach of replacing the original X server seems like a better long term approach, as hardware and computer usage has evolved a lot since the X Window System was first written. AIGLX seems like a good intermediate solution, but the extra passing of information seems unnecessary in the long run. Direct support in the X server sounds like a faster and less resource intensive approach as well.
And finally back to the original question that put me on the path of this research:
“I wanted to ask, what’s really the purpose of that AIGLX part of this how to? And what do you think it could have been that went wrong in my attempt to add that too?”
The reason for the AIGLX part is hopefully clear from the post. Why it didn’t work for you is very strange, and even stranger is that you managed to get Compiz working without AIGLX (or XGL) to begin with. The only thing I can imagine is that Ubuntu managed all those parts for you behind the scenes when you installed Compiz and Emerald. If that is the case it is strange that I had to do it manually.
franko Said,
June 17, 2008 @ 22:46
Thank you for this comprehensive answer, I learned much of it. And also now I’m sure I use AIGLX, too (Ubuntu’s default).
Yes, the most plausible explanation is that apt-get installed all the necessary stuff along with compiz and emerald. Yet, my xorg.conf doesn’t contain all the stuff you wrote is needed to add to it. My “modules” section loads only “glx”, not “dbe” and “dri”; my “device” section doesn’t have ‘Option “XAANoOffscreenPixmaps” “true”‘; and I have no “DRI”, “Extensions” nor “SeverLayout” section at all… But compiz still works just fine… That is what confused me the most. We use the same OS (Xubuntu Hardy) and the same graphic driver (fglrx), yet we don’t have the same graphic related xorg configuration, and your config doesn’t even work on my computer. Maybe it is because the models of the ATI cards we use are different? Still, it is strange that you had to do it all manually…
Michael Plikk Said,
June 18, 2008 @ 20:34
A pleasure to help. I’m learning a lot by looking into these things as well!
The dbe-module is to enable double buffering. This isn’t required for Compiz to work, but it makes everything a little bit better and some applications that run directly on the deskopt require it. The dri module is to enable a Direct Rendering Interface, which is required for other applications to talk directly to the OpenGL library.
Did some more looking into the “XAANoOffscreenPixmaps” option, and it turns out that it isn’t required on newer cards. So after testing I’ve now removed that option from my setup.
I’ve updated the original post as well, to clear up the purpose of those modules.
franko Said,
June 19, 2008 @ 02:11
I did some testing. I found out that the section “DRI” is what masses up my xorg.conf. I tried to load dri and dbe modules and everything is fine. Then I added the “DRI” section. After restarting X, I had to do some further configuration, just like happened before, as I told in my first comment. When I logged in, after a few seconds my screen became blank white… Then I restarted my computer, and after that, my xorg.conf was reset to failsafe. So I restored what I had before and continued my tests. No other section doesn’t seem make problems. When I add all the sections you told to add, compiz doesn’t work anymore… So I think it is something with the “DRI” section. And I am not sure if the other 2 sections has any sense without it.
franko Said,
June 19, 2008 @ 02:32
I withdraw what I was saying!
I tried again to add all the suggested sections together, and now it works fine. So I started to think that the “DRI” section is dependent to the other two. The strange thing is that this time it didn’t ask me anything on restarting X… Anyway, it was probably the “XAANoOffscreenPixmaps” option that messed up my X before, because in these tests I never used it, cause we found out it is useless in most cases, including mine.
Anyway, it doesn’t seem to work any better nor worse with this additional sections. Could you, please, explain what are they for? It seems to me they could be redundant. But I am not an expert, so I guess I could be wrong.
Michael Plikk Said,
June 19, 2008 @ 17:06
It seems like the current version of Xorg enables these modules by default, so it isn’t necessary to load them manually (ie specify them in the configuration file). I think this change happened pretty recently, which is why I needed to manually add them the first time.
If you execute
grep -i 'dbe' /var/log/Xorg.0.logandgrep -i 'dri' /var/log/Xorg.0.logyou should see some lines telling you that the modules were loaded, even if you remove the lines from your xorg.conf file. So all-in-all those lines are useless with the newest version of X, but they don’t do any harm either.franko Said,
June 19, 2008 @ 20:39
True. But now I found out I get some error on DRI module… grep -i ‘dri’ /var/log/Xorg.0.log gives me this output:
X.Org Video Driver: 2.0
X.Org XInput driver : 2.0
ABI class: X.Org Video Driver, version 2.0
(II) “dri” will be loaded by default.
(II) LoadModule: “dri”
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor=”X.Org Foundation”
(II) Loading extension XFree86-DRI
(II) Loading /usr/lib/xorg/modules/drivers//fglrx_drv.so
Module class: X.Org Video Driver
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 2.0
(II) ATI Proprietary Linux Driver Version Identifier:8.47.3
(II) ATI Proprietary Linux Driver Release Identifier: UNSUPPORTED-8.471
(II) ATI Proprietary Linux Driver Build Date: Feb 25 2008 21:22:09
(II) AMD Video driver is running on a device belonging to a group targeted for this release
(II) AMD Video driver is signed
ABI class: X.Org Video Driver, version 2.0
ABI class: X.Org Video Driver, version 2.0
ABI class: X.Org Video Driver, version 2.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
ABI class: X.Org Video Driver, version 2.0
(==) fglrx(0): NoDRI = NO
(==) fglrx(0): OpenGL ClientDriverName: “fglrx_dri.so”
(II) fglrx(0): driver needs X.org 7.1.x.y with x.y >= 0.0
(II) Loading extension ATIFGLRXDRI
(II) fglrx(0): doing DRIScreenInit
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card1
drmOpenDevice: node name is /dev/dri/card2
drmOpenDevice: node name is /dev/dri/card3
drmOpenDevice: node name is /dev/dri/card4
drmOpenDevice: node name is /dev/dri/card5
drmOpenDevice: node name is /dev/dri/card6
drmOpenDevice: node name is /dev/dri/card7
drmOpenDevice: node name is /dev/dri/card8
drmOpenDevice: node name is /dev/dri/card9
drmOpenDevice: node name is /dev/dri/card10
drmOpenDevice: node name is /dev/dri/card11
drmOpenDevice: node name is /dev/dri/card12
drmOpenDevice: node name is /dev/dri/card13
drmOpenDevice: node name is /dev/dri/card14
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) fglrx(0): DRIScreenInit done
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): DRI initialization successfull!
(II) fglrx(0): [DRI] installation complete
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(WW) AIGLX: 3D driver claims to not support visual 0×23
(WW) AIGLX: 3D driver claims to not support visual 0×24
(WW) AIGLX: 3D driver claims to not support visual 0×25
(WW) AIGLX: 3D driver claims to not support visual 0×26
(WW) AIGLX: 3D driver claims to not support visual 0×27
(WW) AIGLX: 3D driver claims to not support visual 0×28
(WW) AIGLX: 3D driver claims to not support visual 0×29
(WW) AIGLX: 3D driver claims to not support visual 0×2a
(WW) AIGLX: 3D driver claims to not support visual 0×2b
(WW) AIGLX: 3D driver claims to not support visual 0×2c
(WW) AIGLX: 3D driver claims to not support visual 0×2d
(WW) AIGLX: 3D driver claims to not support visual 0×2e
(WW) AIGLX: 3D driver claims to not support visual 0×2f
(WW) AIGLX: 3D driver claims to not support visual 0×30
(WW) AIGLX: 3D driver claims to not support visual 0×31
(WW) AIGLX: 3D driver claims to not support visual 0×32
(WW) AIGLX: 3D driver claims to not support visual 0×33
(WW) AIGLX: 3D driver claims to not support visual 0×34
(WW) AIGLX: 3D driver claims to not support visual 0×35
(WW) AIGLX: 3D driver claims to not support visual 0×36
(WW) AIGLX: 3D driver claims to not support visual 0×37
(WW) AIGLX: 3D driver claims to not support visual 0×38
(WW) AIGLX: 3D driver claims to not support visual 0×39
(WW) AIGLX: 3D driver claims to not support visual 0×3a
(WW) AIGLX: 3D driver claims to not support visual 0×3b
(WW) AIGLX: 3D driver claims to not support visual 0×3c
(WW) AIGLX: 3D driver claims to not support visual 0×3d
(WW) AIGLX: 3D driver claims to not support visual 0×3e
(WW) AIGLX: 3D driver claims to not support visual 0×3f
(WW) AIGLX: 3D driver claims to not support visual 0×40
(WW) AIGLX: 3D driver claims to not support visual 0×41
(WW) AIGLX: 3D driver claims to not support visual 0×42
(WW) AIGLX: 3D driver claims to not support visual 0×43
(WW) AIGLX: 3D driver claims to not support visual 0×44
(WW) AIGLX: 3D driver claims to not support visual 0×45
(WW) AIGLX: 3D driver claims to not support visual 0×46
(WW) AIGLX: 3D driver claims to not support visual 0×47
(WW) AIGLX: 3D driver claims to not support visual 0×48
(WW) AIGLX: 3D driver claims to not support visual 0×49
(WW) AIGLX: 3D driver claims to not support visual 0×4a
(WW) AIGLX: 3D driver claims to not support visual 0×4b
(WW) AIGLX: 3D driver claims to not support visual 0×4c
(WW) AIGLX: 3D driver claims to not support visual 0×4d
(WW) AIGLX: 3D driver claims to not support visual 0×4e
(WW) AIGLX: 3D driver claims to not support visual 0×4f
(WW) AIGLX: 3D driver claims to not support visual 0×50
(WW) AIGLX: 3D driver claims to not support visual 0×51
(WW) AIGLX: 3D driver claims to not support visual 0×52
(WW) AIGLX: 3D driver claims to not support visual 0×53
(WW) AIGLX: 3D driver claims to not support visual 0×54
(WW) AIGLX: 3D driver claims to not support visual 0×55
(WW) AIGLX: 3D driver claims to not support visual 0×56
(WW) AIGLX: 3D driver claims to not support visual 0×57
(WW) AIGLX: 3D driver claims to not support visual 0×58
(WW) AIGLX: 3D driver claims to not support visual 0×59
(WW) AIGLX: 3D driver claims to not support visual 0×5a
(WW) AIGLX: 3D driver claims to not support visual 0×5b
(WW) AIGLX: 3D driver claims to not support visual 0×5c
(WW) AIGLX: 3D driver claims to not support visual 0×5d
(WW) AIGLX: 3D driver claims to not support visual 0×5e
(WW) AIGLX: 3D driver claims to not support visual 0×5f
(WW) AIGLX: 3D driver claims to not support visual 0×60
(WW) AIGLX: 3D driver claims to not support visual 0×61
(WW) AIGLX: 3D driver claims to not support visual 0×62
(WW) AIGLX: 3D driver claims to not support visual 0×63
(WW) AIGLX: 3D driver claims to not support visual 0×64
(WW) AIGLX: 3D driver claims to not support visual 0×65
(WW) AIGLX: 3D driver claims to not support visual 0×66
(WW) AIGLX: 3D driver claims to not support visual 0×67
(WW) AIGLX: 3D driver claims to not support visual 0×68
(WW) AIGLX: 3D driver claims to not support visual 0×69
(WW) AIGLX: 3D driver claims to not support visual 0×6a
(WW) AIGLX: 3D driver claims to not support visual 0×6b
(WW) AIGLX: 3D driver claims to not support visual 0×6c
(WW) AIGLX: 3D driver claims to not support visual 0×6d
(WW) AIGLX: 3D driver claims to not support visual 0×6e
(WW) AIGLX: 3D driver claims to not support visual 0×6f
(WW) AIGLX: 3D driver claims to not support visual 0×70
(WW) AIGLX: 3D driver claims to not support visual 0×71
(WW) AIGLX: 3D driver claims to not support visual 0×72
(II) AIGLX: Loaded and initialized /usr/lib/dri/fglrx_dri.so
(II) GLX: Initialized DRI GL provider for screen 0
(II) Synaptics touchpad driver version 0.14.6 (1406)
Warning: LookupDrawable()/SecurityLookupDrawable() are deprecated. Please convert your driver/module to use dixLookupDrawable().
:-/
Michael Plikk Said,
June 20, 2008 @ 14:42
You’re not getting any errors there, the (WW)-prefix indicates that it is only a warning. The parts around it:
(II) fglrx(0): DRI initialization successfull!
(II) fglrx(0): [DRI] installation complete
...
(II) GLX: Initialized DRI GL provider for screen 0
Indicates that the ‘dri’ module is loaded and initialized correctly
I’ve tried to figure out what the warnings mean, but no luck so far. Since everything is working fine, and all modules are loaded correctly, it is probably safe to ignore them.