Weekly Edition
Return to the Development pageRecent Features
| |||||||||||||
Accelerated Indirect GL X
Now there are two 3D-enhanced X servers available: some Red Hat hackers
have released some code which they call Accelerated
Indirect GL X, or AIGLX. "We have a lightly modified X server
(that includes a couple of extensions), an updated Mesa package that adds
some new protocol support and a version of metacity with a composite
manager. The end result is that you can use GL effects on your desktop with
very few changes, the ability to turn it on and off at will, and you don't
have to replace your X server in the process." Much of this code
will ship with Fedora Core 5; for the impatient, there are some
packages available which will make AIGLX work on the just-announced
FC5t3 release. The site includes the obligatory demo
animations and a few digs at Novell's competing XGL work.
(Log in to post comments)
Accelerated Indirect GL X Posted Feb 21, 2006 16:47 UTC (Tue) by nix (subscriber, #2304) [Link] One thing I've been wondering is if anyone's working on standalone compositing managers? They seem to have stagnated while effort's going into making metacity and only metacity compositing-aware.
For those of us who can't abide metacity and use other window managers, this is really not very good news :/
Accelerated Indirect GL X Posted Feb 21, 2006 17:43 UTC (Tue) by james (subscriber, #1325) [Link] Christopher Blizzard writes:And it turns out that building a window manager takes years of work. Sure, you can get one thats working properly in a couple of months but you spend years adding support for all the old strange legacy clients that are out there and adding enough features to make it usable for a wide variety of users. Simply put, its easier to add compositing manager capabilities to a working window manager than it is to turn a compositing manager into a working window manager.
Accelerated Indirect GL X Posted Feb 21, 2006 17:52 UTC (Tue) by mattdm (subscriber, #18) [Link] Since metacity now lets you alt-drag to move windows off the top, I hate it far, far less than I used to.
Accelerated Indirect GL X Posted Feb 21, 2006 19:10 UTC (Tue) by mmarq (guest, #2332) [Link] "" For those of us who can't abide metacity and use other window managers, this is really not very good news :/ ""
Well not exactly.
But one thing that keeps proping up is **WHY** can't all this people agree on some standard way of *Stacking the Blocks*, as one can see in this simple and good explanation: http://www.freedesktop.org/~jonsmirl/graphics.html
What or to whom are the interests in keeping fragmentation high ?... i'm not or pretend to be a black prophet, but if Linux end up failing on the desktop, and UNAVOIDABLY( make no mistakes or have no ilusions) next on the server in very large adoptions,... its no wonder. Wonder is how it could have gained ground and resisted all this time the activism to amper it from the inside, with high industry gurus prognosting its failure on the desktop.
There are plenty of solutions some terrible more performant than the GDI+ of Vista, like the Xara engines. Contrary to the "no desktop" high-priests, creativity and technical ability is very high(some of the very best)in desktop Linux camp, but differentiation *SHOULD* be done from a extensilble standard (stacked blocks) framework.
Accelerated Indirect GL X Posted Feb 22, 2006 4:35 UTC (Wed) by bronson (subscriber, #4806) [Link] Apparently you didn't read the replies to your previous missive. Read the entire thread.
Accelerated Indirect GL X Posted Feb 22, 2006 16:20 UTC (Wed) by mmarq (guest, #2332) [Link] Sorry i've missed it.
"" "XGL is the core for OpenGL driven X Server. XeGL is a standalone x server using the XGL core" [is] a good example where things could "get together"
Wrong. XeGL turns the server inside out to try to make it smaller and simpler. To merge it BACK into the X/XGL server would remove the whole point of this experiment. Did you really not realize this?? ""
Even now can tell *where* my "uneducated guess" about the strategic planning in which Xorg is involved of breacking up into blocks the monolithic XFree, will amper it.
My whole point is not about XGL vs XeGL, which both ultimatly depend upon X11R7 or "X12 ?", but :** Define those "extensible basing" blocks from the kernel DRM structure to the application level, including a new console structure, and then a clear picture will emerge.**
It isn't either drag vs Jon Smirl, but i'm affraid that the later "vision" http://www.freedesktop.org/~jonsmirl/graphics.html is much straighforward, encompassing and complete. You dont need to be a ultimate expert in escavating foundations to stacking bricks to painting to know that a house should be build from the basement and not from the roof.
Perhaps if DKLM is merged into main kernel and a proper "DRM" API defined, "we" could have the involvement of both Nvidia and ATI in kernel development, and everything could be OpenGL 3D based including the user consoles. That IMO would be a superior basement for a clear superior house.
Otherwise, without a clear vision from the basement, i'm starting to wonder if M$ paid vacations, with occasional astroturfing, wouldn't be much more sane, because the alternative *IS* an endless pointless pickering.
Accelerated Indirect GL X Posted Feb 22, 2006 17:22 UTC (Wed) by nix (subscriber, #2304) [Link] Er, the DRM API is stable and has been for ages. ATI and nvidia are as objectionably non-free as ever (although some Radeons, et al, are supported with free software, e.g. the 9250).
I don't have a clue what 'DKLM' is supposed to be.
Accelerated Indirect GL X Posted Feb 24, 2006 3:26 UTC (Fri) by mmarq (guest, #2332) [Link] "" Er, the DRM API is stable and has been for ages ""
If the idea if making it "zillions" of times more *USEFULL* it might worth the risk of some instabiliity...
"" ATI and nvidia are as objectionably non-free as ever ""
Personally, belive me, i dont give a s??t if they are free or non-free, as i suspect do the majority of people on desktop Linux. Isn't not that i dont care about FOSS, i do... and its because of that care that if it(FOSS) must be "forced" trough the path of guerrilla non colaboration upon proprietary players then it has much more to lose than to gain. The *IDEAL*, specialy on the device driver field, would rest on technical structures(code) that invites to cooperation, subjected to the idea, that proprietary players have much more to gain than to lose if they open... making those gains visible by betting on "superior" technical structures... there a possibility could be... DKMS as a start... a truly superior DRM with the post Xbox360 and PSIII graphic generations in mind... etc...
"" I don't have a clue what 'DKLM' is supposed to be. ""
Neither do i. But clearly what i wanted to mean was DKMS http://linux.dell.com/projects.shtml
Accelerated Indirect GL X Posted Feb 21, 2006 22:04 UTC (Tue) by elanthis (guest, #6227) [Link] Stand-alone compositing managers don't work very well. In order to do the things a compositing manager needs to do anything even remotely interesting, it requires very tight integration with the window manager.
You shouldn't be asking for a stand-alone compositing manager, but instead should be asking for a compositing manager to be added to your favorite WM of choice.
The metacity folks actually developed a library to make it easy(-ier) to add a compositing manager to an existing window manager. Other WMs might start making use of that in the future.
Note that both KDE (kwin) and XFCE have built-in basic compositing managers.
Accelerated Indirect GL X Posted Feb 21, 2006 17:10 UTC (Tue) by lacostej (guest, #2760) [Link] 2 accelerated X servers?
What does that mean for users and application developers?
Will this end up in something similar to Gnome/KDE with every distro using their own preferred accelerated packages?
[ I've read the FAQ which answers partly the question of the differences between both. http://fedoraproject.org/wiki/RenderingProject/aiglx ]
Accelerated Indirect GL X Posted Feb 21, 2006 17:59 UTC (Tue) by rossburton (subscriber, #7254) [Link] End users and application developers won't know or care what X server is being used, just like they currently don't are if you are using Xorg or XFree86 or XSun. They both expose functionality via the stardard OpenGL and Render/Composite extensions, and thus Metacity in composing mode will work with XGL and Compiz will work on AIGLX.
The only difference between them is the direction taken to achieve the goal of "spiffy rendering": XGL choses to start from the bottom with the goal of Xegl (the current Xglx should be considered proof of concept), and AIGLX choses to take the current X server and simply implement accellerated indirect GL rendering. Both of these achieve what a composite manager needs.
Accelerated Indirect GL X Posted Feb 21, 2006 21:06 UTC (Tue) by beoba (guest, #16942) [Link] How do the two methods compare on efficiency?
Accelerated Indirect GL X Posted Feb 21, 2006 22:02 UTC (Tue) by Xman (guest, #10620) [Link] Xgl and AIGLX follow basically the same strategy, so from a design standpoint they are equally efficient. Xegl should, in theory, be more efficient.
Accelerated Indirect GL X Posted Feb 21, 2006 23:03 UTC (Tue) by drag (subscriber, #31333) [Link] "End users and application developers won't know or care what X server is being used, just like they currently don't are if you are using Xorg or XFree86 or XSun. They both expose functionality via the stardard OpenGL and Render/Composite extensions, and thus Metacity in composing mode will work with XGL and Compiz will work on AIGLX."
That's the goal, I beleive...
But right now it matters, and it matters a lot and end users and developers have to care a lot about what X server they are using...
(think about it.. Linux has the ability to detect and setup every single peice of hardware on most modern computers. It does it dynamicly and accurately. Udev, hotplug, sysfs, etc etc. Then why do you still have to edit your stupid xorg.conf file or have it manually rebuilt or awkwardly rebuilt everytime you have a hardware change? X should be able to adapt _on_the_fly_, just like every other peice of software. You shouldn't have to restart X to add a second monitor, for instance.)
Why?
Because the OS has to be made to jump through hoops in order to conform to X.org's notions about how to be accelerated. The problem is is that current driver model for X is shit. You have multiple drivers from multiple projects acting on a single peice of hardware.
How well do you think your networking stuff would work if SAMBA had to have control over your nic card? That in order to do file sharing NFS had to have exclusive and direct control over your ethernet controller every time it needed to make a file transfer? That each of these projects had their own hardware drivers and the Linux kernel had to made to work with them...
But that is what you have to deal with right now with X. You have Framebuffer drivers, VGA console drivers, DRI drivers, in kernel DRM drivers, EXA drivers or XAA drivers, etc etc. All from different projects and they have to be simultaniously running and sharing the same hunk of hardware in order to get all the acceleration methods that a end user expects on a modern desktop.
It works.. but it doesn't work very well. It's stability in practical usage is somewhat less then what you experiance with Windows XP or even Windows 98 SE. This is very very bad.
This is why XGL has no future. This is why AIGLX has no future. This is why EXA has no future. This is why the current X.org X server has no future. All these projects will be dead in a few years.
The nice thing about XGL and AIGLX is that they are stepping stones. They themselves will be dead.. but their code and things they figure out will probably live on. Currently XeGL has the most hope of actually being the next generation of Free software X servers, but right now it's going to be worthless until projects like XGL and AIGLX figure out new solutions to major problems.
And of course the best way to find out if XGL and/or AIGLX have good solutions is to use them in the real world!
Also the nice thing about AIGLX is that it's a indirect rendering method. That is you can get acceleration directly from the X server itself instead of having to go through the hardware directly. That is you can get acceleration irregardless of the hardware. That is that you can get acceleration for _remote_applications_ over X networking. (I think) No other operating system or GUI enviroment can do this.
Eventually when Xegl or whatever that ultimately grows from all of this becomes mainstream then it won't matter to the end user anymore.
Your X server would just be another OpenGL applications along with your games, your browsers, and everything else. I won't matter and the OS will take care of configuring and managing hardware instead of Setuid user applications like the xserver. It will have stability improvements, much easier driver development (both Free AND propriatory drivers), etc etc.
It would be much easier to make everything 'just work'.
what a drag :o) Posted Feb 22, 2006 9:18 UTC (Wed) by gvy (guest, #11981) [Link] > That is that you can get acceleration for _remote_applications_ over> X networking. (I think) No other operating system or GUI enviroment > can do this.
$ ssh -X otherhost glxgears
It's only a modest RM7000 but I guess it's hardware-accelerated rendering since the traffic is extremely low (periodic packets, even); running konqueror there and lazily scrolling the page in a small window would yield ~4--8Kb/s.
> I won't matter
Accelerated Indirect GL X Posted Feb 22, 2006 18:33 UTC (Wed) by elanthis (guest, #6227) [Link] "This is why XGL has no future. This is why AIGLX has no future. This is why EXA has no future. This is why the current X.org X server has no future. All these projects will be dead in a few years."
This is all a load of bull.
XGL *is* Xegl. You are perhaps refering to Xglx, which is quite likely to die out in a few years.
AIGLX and X.org are going to be here for a very long time, probably up until X itself is entirely thrown out. Most of your argument is about moving drivers into the kernel, but that really has nothing to do with the majority of the X.org code or with AIGLX at all. In fact, AIGLX will become *mandatory* with all in-kernel drivers (since applications won't be driving the hardware directly anymore with DRI), and X.org is already seeing work to take out all of the user-space PCI probing and such.
Xegl may or may not be the future. There is this little problem where it needs an *entire new set of drivers*. The amount of hardware with adequate working 3D drivers is darn small, especially compared to all the 2D-only drivers around. An X server which is incapable of using the working 2D drivers and being limited to old radeon cards and integrated Intel graphics chipsets isn't going to be very popular at all. Even if NVIDIA and ATI jump on board and provide Xegl-compatible OpenGL drivers, which NVIDIA at the very least is reluctant to do (they have published a paper explaining why the Xegl is flawed from both a hardware and a driver standpoint), X.org + AIGLX is going to be able to do *everything* Xegl can do, and do it on more hardware, and do it just as efficiently.
Also keep in mind that the kernel developers really don't *want* all those graphics drivers in the kernel proper. Especially not the 3D stuff. The duplication between X and kernel framebuffer drivers is unfortunate, but mandatory because the kernel doesn't want the full complexity of the X.org drivers but still needs basic framebuffer access. The future is likely going to see the common elements of the X.org drivers move into the framebuffer drivers and the X.org drivers depending on the framebuffer drivers, but the complete removal of the X.org drivers is pretty unlikely.
Accelerated Indirect GL X Posted Feb 22, 2006 23:24 UTC (Wed) by xoddam (subscriber, #2322) [Link] > (since applications won't be driving the hardware directly> anymore with DRI) Indeed. DRI breaks most of the assumptions made about X displays, and should never have been considered an integral part of X graphics. Extensions to the X protocol providing (potentially) accelerated 3D rendering are a far cleaner way to do it. It should have been possible a decade ago -- I presume it was the sluggishness of XFree86 evolution that prompted the development of DRI.
Accelerated Indirect GL X Posted Feb 23, 2006 11:55 UTC (Thu) by drag (subscriber, #31333) [Link] Well... Think about this for a second:
The current X.org driver model is counter-productive. It's difficult for developers to work with. You have Framebuffer, you have VGA console, you have DRI, you have XAA, you have EXA.
In order to get good performance that end users expect using Free software drivers then you have to get at least VGA console/framebuffer, DRI drivers, AND XAA drivers (or EXA) working simultaniously and sharing the same hardware flawlessly.
All you need, theoreticly, is DRI (or equivelent). That's it. OpenGL (with a small extension) can do everything that all the current drivers do.
Which do you suppose would provide a easier path to getting good Free Software drivers for Linux?
Keep in mind that 2-D only desktop with 2-D only applications is not going to provide the functionality expected and required by the vast majority of Linux users or any other users. It's 3-D or bust at this point in time.
Thats why I say a standalone OpenGL-based X server is the future and anything else based on the current X.org Xserver for Linux is heading for the dust heap. The current drive model we use is ancient and counter productive, it's obsolete and so is any X server that depends on it.
I am not saying that we should replace X.org... By all means NO!!! X.org supports a veriety of X Servers right now. X servers for windows, OS X, and kdrive, and probably a few others besides. I would like to see X.org take XGL and related projects seriously and concentrate on those items. The modular X.org tree was critical for XGL and related projects...
As for modern cards... http://r300.sourceforge.net/R300.php is probably the one of the most important projects right now for those of us that realy care about having a fully Free Software and open source operating system...
Unles you like embedded Intel video chipsets, that is. ;-)
Accelerated Indirect GL X Posted Feb 25, 2006 17:43 UTC (Sat) by elanthis (guest, #6227) [Link] "In order to get good performance that end users expect using Free software drivers then you have to get at least VGA console/framebuffer, DRI drivers, AND XAA drivers (or EXA) working simultaniously and sharing the same hardware flawlessly."
Versus having a set of frambuffer and DRI drivers only. The X.org 2D drivers may seriously just become interfaces to the kernel framebuffer drivers, simplifying that aspect.
Also quite likely is that the kernel loses framebuffer drivers altogether and everything moves into userspace.
"All you need, theoreticly, is DRI (or equivelent). That's it. OpenGL (with a small extension) can do everything that all the current drivers do."
Sure it can.
Of course, you actually have to have OpenGL/DRI drivers. That's the problem. The only open source usable OpenGL 3D drivers we have are the Intel ones. Even the open source Radeon r100/r200 drivers are pretty unstable (comparatively).
"Keep in mind that 2-D only desktop with 2-D only applications is not going to provide the functionality expected and required by the vast majority of Linux users or any other users. It's 3-D or bust at this point in time."
That's complete nonsense. Even Xgl and Compiz don't actually *do anything* useful with the 3D. It's eye candy. People who want to just get work done, and get it done without the delays caused by waiting for a cube to spin when switching desktops or windows to wobble in and out when they open, they are quite likely to turn off all of fun Compiz stuff even if they are running Compiz on Xgl on a top-notch set of drivers.
Not even Vista or Quartz do anything particular novel with 3D-based desktops. The desktops are still 100% 2D. They just use the 3D-acceleration for bling, and not for anything remotely useful.
Desktops are going to be 2D for a very long time to come.
A truly 3D desktop has some big impediments beyond getting a driver framework. The simple fact is we don't have any clean, intelligent way to interact with a 3D desktop using a mouse and a 2D screen, for one. We only have 2D display devices and 2D input devices.
Even if 3D devices are invented, it's going to be a very long time before the devices are common in homes and developers have figured out how to use them to make a compelling, easy, efficient, productive work environment.
"Thats why I say a standalone OpenGL-based X server is the future and anything else based on the current X.org Xserver for Linux is heading for the dust heap. The current drive model we use is ancient and counter productive, it's obsolete and so is any X server that depends on it."
You were doing well until you got the dust heap bit. ;-)
Name one thing that X.org (+ AIGLX) can't do that Xgl can. Functionality wise, they are equivalent.
Even if you are talking about some theoretical, currently non-existant hardware, where only OpenGL drivers exist, the X.org model is still entirely usable. Just take out the 2D hardware drivers and drop in a glitz based driver, just like Xgl.
Now you have a server that *can* run on nothing but an OpenGL stack with full acceleration, but it can *also* run on a driver stack without an accelerated OpenGL anywhere in sight.
Which model seems more generally useful to real people to you?
"As for modern cards... http://r300.sourceforge.net/R300.php is probably the one of the most important projects right now for those of us that realy care about having a fully Free Software and open source operating system..."
Except that they still don't support the cards in a full usable state years after their release, the "stable" r100/r200 drivers are still flaky, lacking in features, and inefficient, and the r500 serious are completely and totally unsupported without even an inkling of a beginning of a project to support them, and that's just talking 2D - let's not even get into 3D.
The more we rely on complex high-end drivers, the less hardware we'll have available, and the more tied we'll be to proprietary driver vendors. I personally am quite fine with the NVIDIA drivers, but large quantities of other Linux/GNU users are not.
Accelerated Indirect GL X Posted Feb 21, 2006 17:23 UTC (Tue) by bk (guest, #25617) [Link] Cool, this is interesting. When the big distro companies compete to provide a next-gen graphics framework, the users are the winners. It will be very entertaining to see which (if either) end up gaining mindshare and becoming the de facto community choice.
My very preliminary take on this is that Red Hat's offering has the implicit upper hand, given the lower cost of adoption plus the greater Fedora userbase. I haven't used either yet, though, so I could be way off base.
Accelerated Indirect GL X Posted Feb 21, 2006 18:09 UTC (Tue) by sbergman27 (guest, #10767) [Link] I understand that currently, Xgl supports more cards than AIGLX, due to the newness of the AIGLX project.
Could someone in the know comment on whether there is likely to be a difference between the two approaches, as far as hardware support, in say a year's time?
How about apps? Do apps have to care? Does one approach cause more breakage than another?
Accelerated Indirect GL X Posted Feb 22, 2006 6:43 UTC (Wed) by jamesh (guest, #1159) [Link] That seems true to the point that AIGLX is only supported for cards with free 3D drivers, and XGL only works really well with the proprietary drivers from nVIDIA and ATI.
Accelerated Indirect GL X Posted Feb 22, 2006 8:28 UTC (Wed) by drag (subscriber, #31333) [Link] Are you sure about the XGL 'only working well with closed source drivers'?
Because I don't beleive that it is true at all from what I've seen. If your using ATI r200 series drivers it should work. If your using nvidia propriatory drivers it should work. It's not going to work if your using propriatory ATI drivers.
If your using Ubuntu Dapper you can use Compiz and XGL right now, there are packages aviable for it.
Accelerated Indirect GL X Posted Feb 22, 2006 15:36 UTC (Wed) by elanthis (guest, #6227) [Link] Their hardware support is basically identical.
Both rely on the same OpenGL extension. Drivers that have the extension will work well, drivers that don't have the extension will not.
NVIDIA helped develop said extension, although their drivers do not yet support it. XGL does run on NVIDIA hardware decently, but not *that* well - there is still a (barely) noticable slow down compared to plain X.org on my machine, at least. AIGLX will likely perform the same.
The only really big difference between AIGLX and Xglx (and I might have this wrong) is that Xglx offers that OpenGL extension in software mode, meaning that Xglx might perform a little better than AIGLX on drivers which lack the extension. There's no reason to believe that AIGLX won't also have a software implementation too, if it doesn't already.
Honestly, the only difference between Xglx is that Xglx accelerates *all* drawing with OpenGL, whereas AIGLX accelerates only OpenGL with OpenGL and uses the 2D drivers to accelerate 2D drawing commands. Of course, individual applications/toolkits can choose to use OpenGL to render 2D (using, eg, Cairo), but with AIGLX that 3D rendering path is not enforced. AIGLX will get much better performance on hardware that has 2D acceleration but no 3D acceleration, and both AIGLX and Xglx will be able perform the same on hardware that supports only 3D acceleration (assuming an optional OpenGL-backed implementation of RENDER in X.org and/or OpenGL-aware client toolkits).
|
|||||||||||||