XGL Development Opens Up

An anonymous reader writes "David Reveman has made the latest XGL source code available for download. This comes a few weeks after development of the project was criticized for being done 'behind closed doors'. There have been huge changes to XGL, the most significant being restructuring of the code, allowing XGL's GLX support to function on other drivers than the proprietary Nvidia one. Xcompmgr can currently be run under XGL with full acceleration provided that the proprietary ATI or Nvidia drivers are used. An OpenGL based compositing manager, 'Compiz' is currently in the works and a release is expected in February. David intends to get the code into freedesktop CVS as soon as possible, after which the code should eventually merge with Xorg."

Comments

Nice to see more openness.

[jZnat]

No free (gratis) software should be proprietary; that's just a general rule! If you're giving your software away free of charge, people generally would like to contribute back whether it be in donations, patches, QA, etc. With a closed-source model, you're blocking off the useful traffic of free bugfixes! If your software is useful in the corporate world, it's also likely that some companies will contribute back if they tinker around with it enough.

Re:Nice to see more openness.

[heatdeath]

Well, there are certain circumstances where it makes sense - if you're not sure where you want the project to go, but you want to give people the benefit of your code for right now. If you opensource it, you're pretty much condemning any potential you had for making money off of the code. Of course, there are those on this forum that would claim that that's wrong...but it's still a valid reason to keep your source proprietary.

Re:Nice to see more openness.

[Anonymous Coward]

When you move out of your mother's basement, you'll learn about this nasty things called NDAs.

Re:Nice to see more openness.

[jZnat]

How do you explain how TrollTech makes money with a GPL'd program (Qt and its official frameworks)? Or how CodeWeavers makes money off of CrossOver Office when WINE is Free in both ways? Or how RedHat makes money off of providing a Linux distro + support when there is Fedora Core, their fully Free distro of RedHat?

Old business models die hard, and the new methods are proving to be a success. Even Novell, IBM, Apple, Sun, and others are benefitting financially from Free software.

Re:Nice to see more openness.

[Anonymous Coward]

Regarding your .sig: if all you want to do with a real live naked lady is *look* at her, no wonder you think Firefox is better!

Re:Nice to see more openness.

[starwed]

There can be licensing issues which prevent the release of code, depending on the legacy of the code itself. That seems to come up with games a lot...

Re:Nice to see more openness.

[Jah-Wren Ryel]

Normally, I would have had to pay programmers to create software for me, but I don't need to employ any programmers to make a profit now.

oooh your sarcasm is soooo clever.

NOT!

Q: Do you know how much you can earn from simply repackaging free software?
A: Exactly as much as that repackaging service is worth and no more.

It doesn't matter if your repackaging software that is critical to a billion dollars worth of business or critical to nobody. The value that you add by repackaging is all that you will be able to charge for in a free market because any other schmoe can compete with your repackaging service. Unless your repackaging adds more value than the other schmoes in the same market, you will never be able to charge more than than the bare minimum. And if you are adding more value, chances are that you are working hard to do it and thus deserve to be rewarded for your efforts.

Re:Nice to see more openness.

[Kjella]

How do you explain how TrollTech makes money with a GPL'd program (Qt and its official frameworks)? Or how CodeWeavers makes money off of CrossOver Office when WINE is Free in both ways? Or how RedHat makes money off of providing a Linux distro + support when there is Fedora Core, their fully Free distro of RedHat?

1. Commercial versions for closed source, "free sample"
2. Need for constant upgrades to make new software work
3. Need for constant upgrades to make new software work
4. Repackaging the works of others, "free sample" of RHEL

There are countless applications where you'd barely be able to scrape together a living if it were OSS. Seriously, how many of the OSS applications you have on your computer have you bought support for? I can tell you mine is a big fat zero. Particularly if you're competing against a good user community for providing support. For a more typical project you may get the odd paypal donation but I sure wouldn't want to rely on that for a living...

Re:Nice to see more openness.

[Bert64]

Most sales come from corporate users, and corporate users are also more likely to buy support.. Joe enduser is not likely to buy support, and is also likely to copy any software his friends have..
Selling software to end consumers is a lot of hassle, and far less profitable than selling to corporate users, so these companies don't sell to end users, they give it to them for free.

Re:Nice to see more openness.

[Bert64]

And in a free market all software would end up being sold at it's true value, which is also pretty minimal. The only way to make money would be in support contracts, and minimal profits from distribution/packaging.

Re:Nice to see more openness.

[Jah-Wren Ryel]

And in a free market all software would end up being sold at it's true value, which is also pretty minimal.

You are correct, up until you used a comma.

The value of software is to the user. If there is a business need for software, it will be created - and that creation will be paid for by the business that needs it and they will be willing to pay up to as much as it is worth to them.

For the last 30 or so years, the majority money spent of software has been to develop it on contract. Shrink-wrap software may die off, replaced by freely downloadable software - but shrink-wrap is only a small part of the total market. Custom development is always where its been at - just look at IBM Global Services, that's pretty much all they do.

Re:Nice to see more openness.

[shird]

Buying support pays for the support staff. What pays for the software developers? If the purchasing of the support is enough to fund your developers, chances are you have very few developers, or a lot working for free out of their parents pockets. Which is pretty much the case for OSS projects big and small. It doesn't scale at all and results in pretty dodgy development. Development (proper development, not quick hacks done by joe in his basement) is extremely slow and poor like this - it will never be able to compete with its commercial counterpart for most projects. (note that is most, not all).

Re:Nice to see more openness.

[eraserewind]

I think his oh so clever point was that even if his service is nothing special, it is still he who is making the money, not the developer. In your words, he is getting "Exactly as much as that repackaging service is worth". The developer is getting zilch.

Re:Nice to see more openness.

[The Great Wazzoo]

I'm not going to make myself any popular by this, but... the OSS community needs to learn to view and promote their work from a market perspective.

The majority of OSS projects is mainly running on proud, and that won't get you anywhere. Now, don't get me wrong! Being proud of your work is absolutely essential. It's essential for getting the job done, for being able to implement your ideas, for, well, being motivated.

But proud is proven to become a killer the instant you're going to sell your product - countless of business don't survive their first years because of just that: proud (and yes, if an OSS project is to survive, it's got to sell its product, although not neccesarily for money). And why would proud be a killer? Because your proud is merely based on YOUR view of the product, and that'll be for the majority of the OSS community the technical view, and the hard reality is that that's NOT of interest to 99% of your audience.

And boy, can proud be persistant, and can your technical background be blocking the view from that other perspective: the customer perspective. Not being able to tame your proud makes that your audience just doesn't get what on earth you're doing, and what value your product is to them.

Keep your proud, and keep the OSS community as technical is it is, but for heaven's sake, learn to communicate with your audience. I'm absolutely sure that you'll then be able to actually sell OS software. Probably not the application itself, but support. At least, that's what counts for businesses, support as guarantee for continuity.

Re:Nice to see more openness.

[Anonymous Coward]

1. Commercial versions for closed source, "free sample"

Not arguing your point, but fyi there's nothing special about the commercial version of Qt. The difference is in the licensing.

Ditto for Redhat. There's no "sample". Everything is open.

Re:Nice to see more openness.

[Bert64]

Well custom development is more closely related to support, your paying people to actively produce (and later maintain) that software..
And that for sure will continue, your paying people to provide a service, and those people will have to actually work to provide that service. I feel very much ripped off by shrink wrapped software, where the people who did work on it have long since moved on and yet we're still expected to pay top whack for it.

Re:Nice to see more openness.

[Bert64]

Well, what redhat/ibm/etc make from support, seems to fund a lot of their developers.. They maintain, improve and bugfix the software that they support, and if you want extra features you can pay for them.. Because the development model is distributed, companies benefit from work done by each other, so each company needs less developers..
You seem to assume that a single company has to develop an entire product themselves, which is the case for proprietary software.. In a distributed model like this, improvements get shared so the development work is spread between multiple support-providing companies. This also prevents a single company from taking the product in a direction potentially undesireable to users.

Re:Nice to see more openness.

[zotz]

" Well, there are certain circumstances where it makes sense..."

There may be certain circumstances where it makes sense, but the example you give is not one.

Releasing your free program as Free Software does not preclude you from making money on it now or in the future.

For one example of where keeping the source closed while giving away the binaries "made sense" think of what MS did to netscape with the release of a free IE.

To come closer to your example, if you think you may want to go the non-Free, non-free per-copy sales and licensing route in the future, then releasing a Free Software version now, for sale or for free, may be creating a competitor for you then you pull the Free from the equation.

There are probably more who would argue that this is wrong, but I may be mistaken.

[I hope that is clear, it is still early for me.]

all the best,

drew
---
http://www.ourmedia.org/node/111123
Tings - an Attribution-ShareAlike novel (sort of GPL for text)

1. Find someone's CC BY-SA novel.
2. Publish.
3. ???
4. Profit.

Re:Nice to see more openness.

[Perl-Pusher]

I'm gonna go out on a limb here, don't you mean pride.

Re:Nice to see more openness.

[The Great Wazzoo]

Lekker snuggere opmerking van jou zeg.

Re:Nice to see more openness.

[po8]

"There are countless applications where you'd barely be able to scrape together a living if it were OSS."

Exactly. Welcome to the competitive marketplace, which is finally returning to software after a long dry spell of monopoly. The OSS folks will be unable to make a living on these "countless" apps, and so will closed-source vendors; arbitrage will drive the price users are willing to pay toward zero. App vendors in niche markets better get used to the idea, because it's already starting to get here. If your business plan doesn't include producing software that a lot of folks want badly, and that involves substantial effort to produce, you have a bad business plan in 2005. Find a different one. Whether your plan directly involves open source or not is somewhat irrelevant to either of these points.

Re:Nice to see more openness.

[Jah-Wren Ryel]

See this message.

Yay CCDN

[Anonymous Coward]

I'm sure freedesktop.org has plenty of bandwidth but let's use http://www.freedesktop.org.nyud.net:8090/~davidr/x gl-svn_100.tar.bz2 anyway shall we?

Re:Yay CCDN

[dolphinling]

No, we shan't.

Re:Yay CCDN

[aichpvee]

You meant to say, "those who can count in binary, those who can't, and those who think they can but really can't", right?

Re:Yay CCDN

[eraserewind]

that would be spelling out the joke for the hard of understanding.

Re:Yay CCDN

[Anonymous Coward]

"There are 11 kinds of people: Those who can count in binary, those who can't, and those who try to tell this joke out loud."

XEGL

[User 956]

How will this impact the development of XEGL?

Re:XEGL

[Fritzed]

Thank you for your sig, that site made my day.

-> Fritz

Re:XEGL

[poofyhairguy82]

How will this impact the development of XEGL?

It won't. The Xegl has been dead ever since Jon Smirl quit working on it. Development will begin again (it seems) when EXA is ready for primetime. So.... years.

Re:XEGL

[octopus72]

In fact, there are some efforts to get it working on R300 DRI driver(works on R200). Both XGL and XEGL need DRI memory management (which is planned in DRI) and proper mode setting support. Currently linux frambuffer has most necessary patches for functional r200, but idea(plan) is to make a separate mdoe-setting library that is cross platform. most hard stuff is there for XEGL.

Another related issue is plug and play for graphic system (jon smirl had idea to probe sysfs for EDID display changes, even have graphic cards cold/hotplugging support, etc).
And there is a need for in-kernel VGA legacy administration (what's the status of that?), which is, AFAIK, a blocker for some multi-card uses.

Luminocity

[Anonymous Coward]

This is exelent news, but what about Luminocity. Still rooting for this fella...
http://live.gnome.org/Luminocity/

Re:Luminocity

[Anakron]

http://live.gnome.org/Luminocity
There. Fixed that link for you.

Re:Luminocity

[poofyhairguy82]

This is exelent news, but what about Luminocity. Still rooting for this fella...

What about Luminocity? It was an experimental window manager created so that some of the Gnome guys could start work on using compositing and to begin to understand the connection between Opengl and the Linux Desktop.

I wrote a guy to install it if you want to try playing with it. Once you do use it you see what it really is- a tech demo. Its not a full window manager (it does not replace Metacity) and it actually seems that the compositor that is going into Metacity borrows almost nothing from it, so now it seems like it was a fun dead end.

Try it, you will see what I mean.

No Games Yet?

[soda160289]

Even with XGL I still dont think many game developrs will jump to linux now. Since Xorg is just now matching some frame rates with windows.

Re:No Games Yet?

[Fritzed]

What exactly do Xorg frame rates have to do with gaming? I mean, I guess minesweeper and other simple windowed games might care, but I don't remember the last time I played a worthwhile commercial game that didn't render itself. Of course no commercial venders are going to use Xorg to render thier games because then they wouldn't run on windows. I really don't understand your statement, is it some sort of FUD?

-> Fritz

Re:No Games Yet?

[Mad Merlin]

If you're talking about 3D acceleration (through OpenGL), the NVidia drivers for Linux are just as fast as the Windows drivers, if not faster. XGL is about rendering a 2D desktop using OpenGL (and thusly, taking advantage of the graphics card moreso to speed up rendering and get nifty effects), which Windows doesn't do. XGL really has nothing to do with games, and Linux isn't "now matching" Windows in any respect, it's pulling further ahead of it.

Re:No Games Yet?

[Mr. Vandemar]

This has nothing to do with games. Read the article.

Re:No Games Yet?

[Wyzard]

and Linux isn't "now matching" Windows in any respect, it's pulling further ahead of it.

Not really -- Vista will be doing this too, with Direct3D rather than OpenGL.

(And OSX has been doing it since day one.)

What it comes down to is that people want nifty translucency and fluid animation effects even in a 2D GUI, and the best way to implement it is by compositing the desktop using the video card's 3D engine. The Composite extension currently available in Xorg facilitates an alternative approach, based on XRender which still uses the video card's 2D engine, and that's quicker to implement, but not as robust or flexible. (And XRender doesn't benefit from hardware acceleration -- they're working on that now, under the name "Exa", but the nice thing about OpenGL is that we already have it accelerated.)

Re:No Games Yet?

[PenGun]

Ahhh /. ... I like the Mod 0 Insightful.

  Damn they dumb here. heh

"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 3 minutes since you last successfully posted a comment"

    Wow ... dumb!

    PenGun
  Do What Now ??? ... Standards and Practices !

Re:No Games Yet?

[mrchaotica]

Not really -- Vista will be doing this too, with Direct3D rather than OpenGL.

Alright, let's see if we can get this straight, because I'm tired of repeating it (or seeing others do so):

VISTA DOESN'T EXIST YET!

In contrast, nVidia drivers and composite work now.

Re:No Games Yet?

[fungai]

XGL is about rendering a 2D desktop using OpenGL

Thanks for the explanation. They should've made that part of the summary.

Re:No Games Yet?

[Tim C]

VISTA DOESN'T EXIST YET!

In contrast, nVidia drivers and composite work now.

True, you can't buy Vista yet - but you can not only download Beta 1 (if you're an MSDN subscriber), you can also download a tech preview of WPF ("Avalon", the new presentation layer).

In a very real way, for a number of people, Vista's compositing stuff works now, too. In fact, I'd not be at all surprised if there were comparable numbers of people running the Vista/WPF betas and XGL.

Re:No Games Yet?

[Trejkaz]

Indeed. Vista doesn't exist yet, and basically everybody by now has heard about how they're crippling OpenGL in it...

Re:No Games Yet?

[entrigant]

Just a few minor corrections :).

The Composite extension currently available in Xorg facilitates an alternative approach, based on XRender which still uses the video card's 2D engine, and that's quicker to implement, but not as robust or flexible.

Repeat after me. There is no formal relationship between XRender and Composite. The Composite extension simply provides a method for an external program to handle how the desktop is rendered. It hands that program a bitmap for each window, and it is up to the program to do something with them. xcompmgr and KDE's composite manager, which is based on xcompmgr, use XRender to blit those bitmaps in the proper order. Luminocity, gnome's next gen window manager, contains a composite manager that uses OpenGL to render the desktop. The point is that composite manager can do whatever it wants to the bitmaps it recieves. It can invert the colors, make it translucent, flip it upside down, or tile a picture of elmo all over every window. That is the power of Composite.

And XRender doesn't benefit from hardware acceleration -- they're working on that now, under the name "Exa"

EXA is the replacement for XAA. XAA and EXA are 2D acceleration architectures. Much like OpenGL is to 3d. They provide the raw methods for hardware accelerate bit blitting, line drawing, 2d polygons, etc. Some cards accelerate more things than others. A video driver can provide 2d acceleration using XAA or EXA and not accelerate the XRender extension. The default configuration for the propietary nvidia drivers does this. However it uses neither EXA or XAA, but a propietary acceleration architecture. Not that it matters much as it is transparant to applications. XRender can, and is accelerated under many drivers. EXA and XAA do not depend on it, though, and it does not depend on them.

but the nice thing about OpenGL is that we already have it accelerated.

We already have 2D acceleration as well. The nice thing about OpenGL is it is usually faster and more feature rich. XGL aims, as far as I am able to tell, to replace all the functionality your typical driver comes with using OpenGL: EXA, XRender, Xv, RandR, etc.

Basically, what this boils down to is that XGL will draw the content of the windows: the text, the buttons, the images, etc. Then, if there is a composite manager, it will send the content of those windows to it, and it will do with them as it sees fit. Once the window contents are sent to composite what happens next is beyond the scope of XGL.

Re:No Games Yet?

[Anonymous Coward]

Indeed. Vista doesn't exist yet, and basically everybody by now has heard about how they're crippling OpenGL in it...

No they're not. They're making the supplied OpenGL driver use DirectX which means even for a DirectX only card/driver OpenGL will still work. If ATI/Nvidia/Other card manufacturer supply an OpenGL driver for their card then that will be used instead of the default driver, just like has always occured.

Basically they're are strengthening OpenGL not weakening it.

Re:No Games Yet?

[Anonymous Coward]

Ah yes, that's true. But the app will be limited to OpenGL 1.4, not OpenGL 2.0. To quote one of my friends, "I've had three-year-old cards that was next to fully compliant with the 1.5 spec!"

Not to mention that if you use a driver from the card manufacturer, Aeroglass will turn off desktop compositing. Atleast the way it stands right now. However, if Microsoft would be so kind to provide the information neccessary this issue could be solved.

So far, they haven't.

Re:No Games Yet?

[cortana]

Thanks for such an informative post. If only this information was actually present in the Xorg documentation!

Re:No Games Yet?

[Wyzard]

I know there's no direct relationship between Composite and XRender -- that's why I said Composite "facilitates" the XRender-based compositing approach. The Composite extension is needed for any sort of compositing manager to work, including one with draws the desktop using XRender.

The problem is that Composite doesn't interact well with things that don't use the 2D pipeline, such as OpenGL and XVideo stuff; by default you can't even enable Composite unless you disable GLX, IIRC. Even if you do use a compositing manager which renders the display using GL, you have a problem when an application creates its own, completely-separate GL context for its own graphics. You have the same problem when something uses XVideo. The difficulty is that these things bypass the 2D pipeline and therefore can't be "intercepted" and redirected to offscreen buffers by Composite.

I read a suggestion somewhere (I wish I could remember where, and I have no idea whether this is planned to be implemented) that a fully-GL-based X server like XGL could use the "framebuffer object" extension found in most new OpenGL implementations to neatly handle this problem. GL_EXT_framebuffer_object, if I understand it correctly, would allow XGL to give an application its own GL context, just like usual, but bound to a "framebuffer object" rather than to the actual screen, and the application would be completely oblivious to the fact that it's drawing into a texture in video memory rather than to the screen itself. The code responsible for drawing the actual screen (a compositing manager, XGL itself, etc.) could then just map that texture onto a polygon or whatever, just as it does with any other window, and bingo: 3D applications running in a window get the same translucency, wobble effects (a la Luminocity), and other such eyecandy that everything else does. That's not something that can be done with plain old Composite on a 2D display, AFAIK.

Re:No Games Yet?

[Anonymous Coward]

Doom 3 and Unreal Tournament 2004 have official Linux releases. WINE runs World of Warcraft fine with one patch. Cedega can run Steam/Half Life 2, and I think WINE can almost do that too. (or maybe it already can?) All of these run through OpenGL (native OpenGL in Doom and UT, OpenGL +wGL though WINE for WoW, and DirectX wrappers to OpenGL for HL2). So any improvements to how X and OpenGL interact will improve things for people who use Linux to play those games.

Re:No Games Yet?

[Mad Merlin]

The problem is that Composite doesn't interact well with things that don't use the 2D pipeline, such as OpenGL and XVideo stuff; by default you can't even enable Composite unless you disable GLX, IIRC. Even if you do use a compositing manager which renders the display using GL, you have a problem when an application creates its own, completely-separate GL context for its own graphics. You have the same problem when something uses XVideo. The difficulty is that these things bypass the 2D pipeline and therefore can't be "intercepted" and redirected to offscreen buffers by Composite.

Not entirely true. With the radeon drivers (and a Radeon card...), you can enable GLX with Composite and EXA no problem, I just did that. 3D acceleration and Composite aren't mutually exclusive, but they do cause interesting things. If I run glxgears with Composite enabled for example, glxgears won't be composited, and the GL area will be rendered on top of other things. Video playing isn't quite as problematic, it can't be composited either, but it doesn't have the rendering on top issue for me, so essentially it just pretends Composite isn't there. I can't test on an NVidia card at the moment, but I do know that GLX with Composite isn't the default there (but can be enabled), as it was not stable with the 7xxx drivers at least, however, the 8xxx drivers are supposed to have greatly improved Composite stability.

With regards to solving these issues, it should be interesting to see what's done.

Re:No Games Yet?

[Wyzard]

To the best of my knowledge, it's impossible to composite video displayed by the video card's overlay hardware, which is what XVideo typically uses. The video frames are processed by a completely separate portion of the video card, and all the 2D hardware sees is the chroma-key color (typically blue) that the overlay uses to determine where to superimpose the video. You could get composited video by using ordinary bitmap-drawing operations instead of the overlay, but then you lose the benefit of hardware-accelerated colorspace conversion (YUV to RGB) and scaling, both of which are fairly intensive operations.

On the other hand, it is possible to do those operations in hardware using the 3D pipeline: colorspace conversion can be done by pixel shaders (or so I infer from the article's mention of GL_ARB_fragment_program) and scaling is a normal part of the process of drawing texture-mapped polygons. So an OpenGL-based XVideo implementation can do its work using the 3D hardware rather than the overlay hardware, and the result is video frames in OpenGL textures which can be mapped onto the screen in any way the user wants.

huh?

[bcrowell]

Can anyone translate this into English? What is XGL and why should we care?

Re:huh?

[MichaelSmith]

What is XGL and why should we care?

I googled around for it. It seems to be an openGL based X server. I know of a large HMI development project running at the moment which may wind up deploying on windows (as opposed to Linux) due to the faster OpenGL implementation under windows.

Something like this could tip the balance.

Re:huh?

[ArbitraryConstant]

It lets the system offload graphical operations onto the GPU, like Quartz Extreme on MacOS. Things like transparency get a lot easier to do.

Re:huh?

[coolGuyZak]

XGL is a hardware accelerated x-server, which uses the 3D pipeline to render graphics. We should care because it will allow future developers to create whole manner of different effects (vector graphic scaling & rendering, interesting window effects, pixel shaded effects (bump mapping buttons), etc).

If you are in the windows or mac worlds, there's not much of a reason to get excited... OSX already does this, and Vista will as well. But for those of us in *nix world who want eye-candy, it's quite A Good Thing (tm).

Re:huh?

[ArbitraryConstant]

I should add that OpenGL support is already available, but XGL allows the X server to transparently use it in a way that's compatible with existing applications.

Re:huh?

[Lisandro]

Exactly. Mod parent up.

Re:huh?

[vandan]

No.

If you want a faster OpenGL implementation, then you want to optimise Mesa and the individual video card drivers.

XGL is an X Server that runs on OpenGL. It won't make your OpenGL drivers faster - it's simply an OpenGL client ... ie an application that runs on an OpenGL system.

Re:huh?

[cciRRus]

So basically, you're saying that it will revolutionize the way I use xterm on my X server? I can't wait...

Re:huh?

[PenGun]

Indeed what we've all been waiting for, a 3D Gl accelerated xterm. I can't imagine the profound effect this will have on my kernel compiles (2.6.15 as we speak).

  Still I did spend many many hours testing Utah-Glx and I hope some of that is here.

      PenGun
    Do What Now ??? ... Standards and Practices !

Re:huh?

[Anonymous Coward]

XGL is the missing piece of the puzzle which will allow the Linux desktop to have fancy effects to equal or exceed OS X and Windows Vista.

Here is a video demo of the types of effects which become possible with XGL. Note the translucent video playing while being warped and composited with the background window, and simultaneously being displayed live in miniature in the workspace pager to the right.

OS X's "genie" effect, Windows Vista's "frosted" window effect, *real* transparent terminal windows, crazy animated wallpapers, they will all be possible with XGL. But eye candy is not the only use of XGL; it makes possible long-overdue improvements to the Linux desktop experience. OS X's Exposé window management tool will be possible to duplicate on Linux. Window resizing is smoother in the experimental XGL window managers because window borders are drawn synchronized with their contents. Window moving is also faster because window contents are cached instead of drawn on demand. Best of all, all this eye candy will require *less* CPU power than it takes today to draw a screenfull of antialiased text, because OpenGL brings the full power of today's 3D cards to bear on your existing ordinary everyday applications. Today when you're surfing the web your GeForce or Radeon is sitting idle while your CPU draws all the text and graphics. XGL will put that power to work, freeing up your CPU and allowing way more eye candy to boot.

(Note that this video is only a demo and *not* a proposal to make wobbly windows the default in GNOME or KDE. I don't want to see those replies with rants about how you hate eye candy, and you think Linux should have stopped improving after it could run TWM with Emacs in an XTerm on your Pentium 133.)

Re:huh?

[zootm]

Arguably, though, a greater reliance on OpenGL for desktop applications could lead to more and better OpenGL driver implementations. It's a knock-on effect at best though, yes.

Re: huh?

[O_D_Evans]

This was posted a while ago on /.,can't find the original link. I did save the video demo from that article and have posted it here:

http://media.putfile.com/xgl_wanking

Re:huh?

[WindBourne]

First, it will probably speed up xterm. If for no other reason than offloading graphics processing from the CPU to the GPU. But from that, I think that we will see some nice stuff. One good example is konsole. I suspect that in the future, all the xterms will adopt the multi-session ability of konsole. Likewise, the nice backgrounds that konsole has, was "borrowed" from Enhancement's e-term. Speaking of, E-term was pretty cool several years ago (I have not tried enhancment in some time).

But revolutionize how you USE your xterm? Only if you are graphics coder :)

Re:huh?

[cciRRus]

First, it will probably speed up xterm.

From my minimal knowledge of XGL, it seems to provide acceleration for 3D graphics processing; however for simple X11 applications like xterm, they do not require any 3D capabilities. So, would XGL help in 2D acceleration as well?

Re:huh?

[Anonymous Coward]

I've understood that Nvidia's Linux drivers has the same OpenGL engine that is in Nvidia's Windows drivers so there shouldn't be notable difference in the performance.

Re:huh?

[Fred_A]

Hey ! I ran Emacs in an Xterm in twm on my 486 50 and I liked it !
Oh yes, I forgot...

You insensitive clod !

Re:huh?

[Anonymous Coward]

Linux 2008 = Windows 2006 = Mac 2001.

Re:huh?

[True Grit]

XGL will be a client to OpenGL and will do ALL of its work in 3D. OpenGL can be used for *both* 3D and 2D. Just think of 2D as 3D with one dimension fixed, i.e. an x, y, and z where z is always 0. That's why the summary mentions that the advanced 3D cores on today's video cards can do everything that 2D does and usually do it faster. The 3D pipelines on today's cards are now much more powerful than the circuitry set aside for 2D.

Re:huh?

[orasio]

Enlightenment, not enhancement
http://www.enlightenment.org.au/

It still is pretty cool.
Eterm seems to be dead, though, at http://www.eterm.org/
Term is very elegant. I just traded it for gnome-terminal, when I started using gnome, for shortcut-consistency, and to stop alienating other users. But its looks are much better than other terminals.

Re:huh?

[Anonymous Coward]

Screenshots: http://www.linuxedge.org/index.php?q=node/39

Re:huh?

[cortana]

If you want to run xterm with decent fonts (via Freetype, via Xft) then you take a huge speed hit. I think Xgl speeds up RENDER, which will speed up the drawing by Xft of anti-aliased fonts.

I always thought gnome-terminal was innately slow, until I found that the lack of speed is due to Freetype drawomg anti-aliased fonts. If I fire up an xterm -fa monaco, xterm runs even slower than gnome-terminal!

Re:huh?

[amightywind]

Can anyone translate this into English? What is XGL and why should we care?

Back in the early 90's I used a 3D library from Sun called xgl. It was Sun's attempt to compete with SGI's GL. Quite nice too. I wonder why it was never release as software libre.

Re:huh?

[octopus72]

I shall write something about XGL's workings. It is a X server implemented as GL program, using GPU to manipulate bitmaps which are therefore stored in video memory. It cun run directly using linux framebuffer and MESA, or use another X server to get stuff as input, graphic mode setting and direct hardware (DRI) access.

As app bitmap data is located in vram, GL-based composite manager (in the works by DavidR) is essentially GL program which manipulates video ram data of all windows using GPU directly (and as such can be blazingly fast on moder GPU's) to render final screen. XRender is a part of X protocol: commands are issued by applications to xserver to do requested vector operations (in similar way to Cairo) and draw to resulting bitmaps. Drawing it to bitmap is done here by XGL,a GL X server program, which does this using GPU to calculate and write result into video memory bitmap. XGL also other X drawing operations besider Xrender in similar fashion.

Important point here is that XGL uses glitz for access to GL protocol. This has nothing to do with Cairo, it is merely a usage of what has already been done as a good vector GL interface. Taklking about cairo-based apps, they only need to use XRender cairo backend to get result hardware accelerated. They can also use glitz with direct GL, but then it opens new GL stack and avoids XGL render acceleration completely (in case of indirect GLX it isn't like that, it still goes all over XGL). Compositing manager (and possibly XGL) will still have access to those direct mode rendered textures, via special GL extensions (which it uses also to access XGL bitmaps that are part of regular X apps).

I think hardest part is to get good memory management working, but also a GPU scheduler could be required for simultaneous usage of GPU by more processes (see MS plans, in vista they will have both). Also, DRI/MESA needs to get some tweaks and new extensions to allow all possible windowed GL apps to run in XGL alongside composite manager and XGL itself (in full screen I guess XGL/composite manager can be suspended).
It remains to be seen how fast NVIDIA will folow that development with their proprietary driver. For ATI I don't care yet because there is open R300 driver working with most except the new X1000 series (and they use DRI so it won't be so hard to integrate their stuff).

In more distant future I hope someone will come up with vector-based compositing (i.e. storing vector based data in memory which compositing manager transforms into final bitmap), and maybe there will be a new and simple method (accompanied by new protocol extension) for creating 3D apps, similar to what MS is doing with Avalon.

Re:huh?

[ArsonSmith]

Exactly. It'll be awesome to be able to run an xterm in the back ground with top or sar or similar running while I do tests in a semi-transpert Xterm above the other, and be able to watch everything in real time.

Yes this does even benifit xterms

Re:huh?

[iabervon]

In particular, it uses the OpenGL engine for everything, instead of only using it for 3D. And, actually, I don't think OS X or Vista is using OpenGL as the common layer; I thought they had these things rendering the windowing system with drivers for the particular video card, rather than having per-card drivers that implement an independant 3D standard, and rendering the windowing system with that standard. What isn't new is having the video drivers use the 3D functionality of the cards; what is new is using this functionality only through a standard interface. It doesn't matter for the quality of the eye-candy, but it does mean that there's less stuff happening in the proprietary drivers, and those drivers are providing a standardized API.

What I would like to see would be closed-source nVidia OpenGL drivers that run in userspace, using a generic API for access to the device. (For that matter, it would be great if they'd specify their card's bus behavior, so that the kernel could present nVidia cards to userspace as a character device that nobody knows how to use, but which will at least not screw up memory or lock the bus).

Re:huh?

[maw]

But for those of us in *nix world who want eye-candy....

It's not just eye-candy, though. Exposée is very useful. That it looks cool is just a bonus. Because of it, I don't miss workspaces much on my mac.

I once tried out a workspaces extension, but I didn't end up using it for long. If it were key-bindable, though, I probably would have. Having exposée-like functionality and workspaces, both comfortable to use, will someday be a killer combination.

Re:huh?

[Anonymous Coward]

Nice one... I believed you enough to try the experiment. Same output to both gnome-terminal and "xterm -fa monaco" gives these result: gnome-terminal 40% CPU utilisation, xterm 1%.

gnome terminal is a piece of shit and a bloody disgrace... and I'm a GNOME user!

Re:huh?

[cortana]

Well then, frankly, you must have fucked up.

$ dd if=/dev/urandom bs=1M count=1 | xxd > data
1+0 records in
1+0 records out
1048576 bytes transferred in 0.614494 seconds (1706405 bytes/sec)

$ time xterm -fa Monospace -fs 8 -e cat data

real 1m25.087s
user 0m4.145s
sys 0m0.379s

$ time gnome-terminal -e 'cat data'

real 0m5.292s
user 0m3.348s
sys 0m0.200s

Once both terminals use the same font rendering system (Xft), the same font (Bitstream Vera Sans Mono, 8 points) and the same window size (80x24), gnome-terminal (version 2.12.0) is must faster than xterm (version 240)! In addition, xterm flickers like hell whereas gnome-terminal's display is rock steady.

I think http://mces.blogspot.com/2005/10/gnome-terminal-pe rformance.html is the blog post that triggered me to perform my own experiment.

Re:huh?

[obeythefist]

Thankyou for the exposition. Slashdot has a severe flaw in article posts - the editors never bother explaining what particular applications are for.

Open source code/products/applications are often named in very unintuitive ways.

Slashdot editors either do not know what the code is for so release the article without exposition, or assume (wrongly) that everyone knows what the code/product/application does and therefore does not provide exposition, or are simply too lazy to edit where required.

Re:huh?

[zeenixus]

quote:
I googled around for it. It seems to be an openGL based X server. I know of a large HMI development project running at the moment which may wind up deploying on windows (as opposed to Linux) due to the faster OpenGL implementation under windows.

Something like this could tip the balance. /quote

Well then, dare I say those considering Windows should take a look at what Vista does with OpenGL. Namely, how it does away with it and emulates it by converting OGL to Direct3d.

Now, seeing as how nvidia drivers for linux are on par with their windows counterparts I'll leave you to draw your own conclusions.

Unfree

[Brandybuck]

Xcompmgr can currently be run under XGL with full acceleration provided that the proprietary ATI or Nvidia drivers are used.

What good is Open Source if it's inextricably tied to proprietary software? Where do I send my money to get someone to write a Free Software video driver?

Re:Unfree

[Anonymous Coward]

If you sent money to David Reveman I suspect he would be happy to write a completely free version. But it wouldn't be a free version then, would it?

Re:Unfree

[Ruie]

Two things you can do (in no particular order):

• Ask (politely) ATI to provide 3d specs
• Work on DRI project (r300 driver for example)

Re:Unfree

[Anonymous Coward]

> Where do I send my money to get someone to write a Free Software video driver?

I don't know, and I wish there was one too, but:

I think people generally misunderstand the sheer amount of work put into those proprietary graphics drivers. It's not something where you can throw a few bucks at some garage coders and turn out the same thing. These are done by large teams of highly payed developers (I think 100 developers is the right order of magnitude, plus or minus), working for years. It takes *serious* amounts of money to fund that sort of development staff, and it's not something you and me and a few other likeminded folks are going to be able to fund.

Can you get *some* working graphics driver for a lot less money? Of course. But you can't get what the proprietary drivers do, in terms of performance and functionality, on the cheap.

Just tryin' to inject some reality into the picture here :D

Re:Unfree

[Anonymous Coward]

Away from nVidia.

ATI up to Radeon 9250 (r200) are well supported, newer cards (r300) are starting to be supported with X.org 6.9 / 7.0.

Re:Unfree

[nathanh]

I think people generally misunderstand the sheer amount of work put into those proprietary graphics drivers. It's not something where you can throw a few bucks at some garage coders and turn out the same thing. These are done by large teams of highly payed developers (I think 100 developers is the right order of magnitude, plus or minus), working for years. It takes *serious* amounts of money to fund that sort of development staff, and it's not something you and me and a few other likeminded folks are going to be able to fund.

The same thing used to be said about operating systems.

Re:Unfree

[Anonymous Coward]

Where do I send my money to get someone to write a Free Software video driver?

Ahh, the irony....

Re:Unfree

[Anonymous Coward]

> The same thing used to be said about operating systems.

Yes, and I'm not saying it's impossible, but I think a lot of the work put into Linux *is* done by teams of payed developers. They're just payed by IBM, by Sun, etc. Linux has come a long, long ways because of the work done by those folks.

The other issue is that there are many trade secrets in nVidia's and ATI's hardware, so they are not so likely to just hand over the HW specs, even if you could come up with a big enough team to tackle the issue to begin with.

Re:Unfree

[Anonymous Coward]

your arguement boils down to:

blah blah blah. oss.... blah blah blah. nvidia ati blah blah blah

Re:Unfree

[PitaBred]

How much money do you have? Because you're gonna have to buy the IP of a LOT of companies in order to open source their stuff. Lots of proprietary stuff in the chips and the drivers, from what I hear.
And FYI, the older Radeons (up to 8500 I believe?) have a decent open source driver.

Re:Unfree

[poofyhairguy82]

Where do I send my money to get someone to write a Free Software video driver?

You don't. Nvidia and ATI could not care about you money- the only reason they made drivers for Linux in the first place was to sell high end cards to render 3D scenes.

If you really want to support open drivers, buy an ATI 9250 and help test EXA and Xgl on there. That is the best card we have with open drivers, and it seems like it will be on top for a LONG time.

Re:Unfree

[vandan]

I disagree.

The opensource R100, R200 & R300 drivers were written by the DRI developers. ATI provided some incomplete and contradictory documentation for the R100 & R200 to some select developers who had to sign an NDA. All the coding has been done by DRI developers. The R300 has been completely reverse-engineered.

Now. Check out all 3 drivers. They not only work, but they work incredibly well. In fact they are faster and more stable than ATI's drivers, except for in some key areas ... usually areas where more documentation is required.

The simple fact is that the very thing you're saying is impossible - opensource developement of top-quality drivers - has already happened. Not only that, despite your suggestion that they're not up to it, R300 developers continue to reverse-engineer and code for the current and upcoming cards from ATI. Pretty neat, eh? Check out the list of apps the R300 can run - you'll be surprised.

Re:Unfree

[Anonymous Coward]

> The same thing used to be said about operating systems.

No. Torvolds and others knew everything there was to know about the underlying PC/386 architecture. Furthermore what was needed to support high-performance Unix applications was also well known.

Meanwhile, people know next to nothing about 3D hardware. Furthermore, they are ignorant about what's needed to run Doom3 with high performance or Pro GL software with no rendering errors.

Re:Unfree

[BillyBlaze]

I have an idea - nVidia could subsidize the tremendous task of writing open source video drivers with some sort of side business, like, oh I don't know, manufacturing video hardware.

Re:Unfree

[WindBourne]

Meanwhile, people know next to nothing about 3D hardware

And yet, 3D hardware on unix systems (ahem; SGI) have been around since the 80's and many of those same people contribute not only to either Linux or BSD, but have written many of the core texts on things.

Re:Unfree

[dolphinling]

And even better: Buy a card from the Open Graphics Project when it's available (first half of this year, if all goes well).

It's certainly what I'm doing (just sent back an Nvidia 6600 something-or-other I got for ACGPD).

Re:Unfree

[Anonymous Coward]

I see a contradiction in what you just said.

1) ATI released, for free, the specs for some of their now older hardware.

2) You would have to buy IP from a LOT of companies to get the new stuff open sourced.

Is it really that likely that in one generation of video cards ATI went from being able to give away their specs for free to it being prohibitively expensive for them to do so?

Re:Unfree

[poofyhairguy82]

Now. Check out all 3 drivers. They not only work, but they work incredibly well. In fact they are faster and more stable than ATI's drivers, except for in some key areas ... usually areas where more documentation is required.

Really? Everything I read tells me that the crappy closed ATI drivers are still faster when it comes to 3D than the open source drivers.

I mean...its cool that at least one set of cards with decent 3D hardware has open driver, but those drivers are not for gamers to use. Its for me to use to get EXA.

Re:Unfree

[mrchaotica]

Meanwhile, people know next to nothing about 3D hardware.

Gee, I wonder why. Could it be because NVIDIA AND ATI REFUSE TO RELEASE THE SPECS?!!!

Lets make something very clear here: Some open-source drivers with 3D support do exist, for example, for the ATI Radeon 9200 and below (IIRC). The only thing holding people back from writing accelerated drivers for more modern cards is the fact that they've got to reverse-engineer the hardware first!

Re:Unfree

[Anonymous Coward]

Free software has nothong to do with money. It's all about liberty.

Re:Unfree

[Kjella]

Lots of proprietary stuff in the chips and the drivers, from what I hear.

Which isn't "need-to-know". To write drivers you need specs on what the chip can do, not how. If you have the documentation for the Linux API and the documention for the chip, you can find your own way from A to B. Have you looked at what developers are able to achieve just by reverse engineering? If they could stop wasting time on that and getting straight down to coding up optimized algorithms, OSS drivers would take a huge leap ahead (is that TM Intel now?)

Re:Unfree

[zootm]

Which would be fine if everyone was using SGI graphics cards, but they're not. These architectures are hugely complex, differ a lot, and are basically undocumented to the people writing the open drivers. Writing effective graphics drivers is hard enough when one knows the specifications of the hardware, but when reverse-engineering has to be used to discover how to even interface with the cards, it becomes an even more difficult task. That's what the big issue is here.

Re:Unfree

[Jah-Wren Ryel]

How much money do you have? Because you're gonna have to buy the IP of a LOT of companies in order to open source their stuff. Lots of proprietary stuff in the chips and the drivers, from what I hear.

That's the same tired old line we've been hearing since the days before XFree86, when it was just X386. And you know what? It's all bullshit.

All the cards through-out the years that vendors have kept proprietary, they all eventually received 3rd party open-source drivers and you don't hear a word about those 3rd parties being sued or otherwise harassed for violating anyone's IP. All it took was time and effort for people to reverse engineer the proprietary ms-windows drivers.

Re:Unfree

[msormune]

Oh, just put a lid on it. Open Source R300 drivers are so far behind when compared to the official ATI drivers, it's hard mention them in the same sentence with a straight face. R300 driver is still pretty much a hack, and is very slow when compared to the binary drivers. It doesn't support RENDER extension, and OpenGL support is still also lacking. People are also complaining about lockups in a regular desktop situation and newer hardware support is also in the works (hopefully).

Re:Unfree

[Lussarn]

It takes *serious* amounts of money to fund that sort of development staff, and it's not something you and me and a few other likeminded folks are going to be able to fund.

You are talking about a different issue. When he said he wanted a free software driver he did not said the developers working on it shouldn't be payed. Nvidia and ATI can throw 1000 paid developers on the problem for all I care and still develop a Free software driver.

Nvidia would still sell the hardware even if the driver where Free software. What good is the driver without the hardware?

Now, you would maybe say Nvidia can't open source the driver because they don't own all of it. I say bullshit, If there is a will there is a way. The will just isn't there today, but the future might change that.

Re:Unfree

[c0l0]

Actually, the best (as in "fastest") card with free hardware glx support of the R2X0-series of Radeon chips is the "original" Radeon 8500 with 275MHz clock on GPU and RAM. The Radeon 9250 is just some stripped down (in terms of pixel-pipelines or so) version of the original R250.
 
However, XOrg 7.x comes with a driver called "r300", supporting glx on more recent hardware, ranging from the Radeon 9500-series up to the X850, I believe. There's just no way to utilize the cards' shaders, yet.

Re:Unfree

[m50d]

Go out and buy a voodoo 5. Unfortunately they're getting older (and rarer) every year.

Re:Unfree

[10Ghz]

There are lots of free video-drivers. X.org ships with quite many. There are free drivers for NVIDIA as well. The reason why XGL only works properly with those proprietary drivers can be numerous, but that doesn't mean that free drivers don't exist.

Re:Unfree

[Kjella]

Meanwhile, people know next to nothing about 3D hardware. Furthermore, they are ignorant about what's needed to run Doom3 with high performance or Pro GL software with no rendering errors.

Let me guess, because they get no specs, they don't get to know the capabilities of the chip and they don't get to know about the chip's quirks? They poke and prod at it, but it's like trying to tune a car for performance with the hood welded shut. I think it's quite impressive they get it running at all.

Re:Unfree

[Anonymous Coward]

Hmmm... I doubt that card is going to play Half-Life 2 well.

Re:Unfree

[Anonymous Coward]

Word on the street is that XGI may soon be releasing full source to their DRI driver (The source for their non-DRI driver is already available). This could only be a good thing for XGI, and might even spur other mid-range manufacturers to open up (S3, are you listening? Were are the open Deltachrome/Gammachrome drivers?)

Re:Unfree

[eraserewind]

That's why we won't be sending him any money :)

Re:Unfree

[BobFunk]

I don't know, and I wish there was one too, but: I think people generally misunderstand the sheer amount of work put into those professional operating systems. It's not something where you can throw a few bucks at some garage coders and turn out the same thing. These are done by large teams of highly payed developers (I think 100 developers is the right order of magnitude, plus or minus), working for years. It takes *serious* amounts of money to fund that sort of development staff, and it's not something you and me and a few other likeminded folks are going to be able to fund. Can you get *some* working operating system for a lot less money? Of course. But you can't get what the proprietary operating systems do, in terms of performance and functionality, on the cheap. Just tryin' to inject some reality into the picture here ;)

Re:Unfree

[jejones]

People are also complaining about lockups in a regular desktop situation...

Oh...in that case, they've achieved parity with ATI's proprietary driver. I got sick of the problem with nVidia's proprietary drivers causing X to hang and eat 99+% of CPU (there's a two-year-old thread on their forum on the problem), bit the bullet and got an ATI card sufficiently recent that ATI deigns to provide a proprietary Linux driver for it--and a couple of days ago woke up to find the same problem my wife's computer had with an ATI card, i.e. the computer irretrievably wedged with a 3D-using screensaver image on the display.

I look forward to the day I can order cards from the Open Graphics Project and tell nVidia and ATI that they can use their proprietary hardware and drivers for reaction mass.

Re:Unfree

[msormune]

One thing that should be always taken into consideration is the fact that binary drivers are always meant to work WITH A SPESIFIC version of Xfree/Xorg and Linux kernel. I think there may have been too many internal changes with those in the last year for nVidia and ATI to support them perfectly. Not to mention there may be desktop crash related bugs with XFree/Xorg or kernel themselves, as people use kernels agpgart and such.

I still have a ATI 9800Pro myself and I really hated ATI binary drivers, also. Switched back to Windows since, because I got tired of fighting with stuff like tv-out. A little irony is in the fact Windows XP is really much more stable than with Xorg 6.8.2 and an ATI card. Some day I will probably switch back.

But the fact is ATI and nVidia really do not have to care about Open Source or Linux. The market segment is just too small to make a difference.

Re:Unfree

[MattWhitworth]

Ah, but is there a free open NVIDIA driver in development?

Re:Unfree

[cortana]

Remember that Microsoft own a lot of patents in the 3d graphics field. Perhaps their licensing policy prevents licensees from disclosing their hardware specifications to third parties--effectively preventing the creation of Free Software drivers.

Re:Unfree

[zdzichu]

I don't get it. I have Matrox G550 with 100% Open Source driver. It allows me to play Quake3 at almost 50+ fps. And somehow this card is unable to draw few rectangles for a desktop? Something is not right here.

Re:Unfree

[cortana]

Half-Life 2 isn't going to be ported to Linux any time soon anyway.

Re:Unfree

[cortana]

During this time Microsoft bought a *lot* of 3d acceleration patents from SGI....

Re:Unfree

[be-fan]

The way XGL works is that it represents window buffers are textures. This requires the OpenGL driver to support the pbuffers extension, which (IIRC), none of the open source drivers do.

Re:Unfree

[Anonymous Coward]

Well to be honest, all I ever heard was "don't ever use an ATI card with Linux if you value your sanity" (or something similar ;-)

I tried myself because I had a really good ATI card left over from my Windows machine but I never could get it to work well for games. Since switching to an nVidia card (and using ATrpms driver packages) I've been more than satisfied.

So although I don't like it that the nVidia drivers aren't open source they sure seem to care, at least sufficiently to make drivers that actually unlock most of the capabilities of their latest cards.

Re:Unfree

[Anonymous Coward]

I agree also.

Whilst plagued by a bad case of forkitis (or really just an ego trip by the original developer), the Via Unichrome drivers (now the Openchrome drivers) are a great example of how a community based project can actually get the job done.

Via didn't provide proper documentation, and their open source releases were only wrappers to proprietary binaries. A leaked datasheet or two later and the open source drivers have provided a full 2D DRI interface with some good work being done on 3D, as well as a few nessecary goodies for that chipset like the XvMC interface for motion compensation acceleration in xine/mplayer and proper modelines for PAL via the TV encoder (most of the world doesn't use 60Hz!).

If unlike nvidia, most gpu manufacturers choose to snub oss developers and/or release bodgy drivers nobody wants to use (that's the unlike nvidia bit - i very much like the nvidia drivers, even though they're closed), it usually just signals a big fat waste of time for the manufacturer, as people will develop what they need. ... and most developers will tell you that the difference between 1 and 10 developers is huge, and between 10 and 100 developers may not even really mean all that much. Communication overheads, lack of passion, poor management strategies, internal politics > wasted time.

Re:Unfree

[Arandir]

I'm already pledged to do that.

Re:Unfree

[Arandir]

I use the Open Source R200 driver, and it works very well. Which is why it pisses me off that XGL is deliberately ignoring it. While the R200 3D isn't as good as the proprietary 3D, it's still very usable. It's not up to hardcore gaming, but it's more than adequate for XGL.

Besides, as a FreeBSD user, Open Source is the only way I'm going to get native drivers. Even if the proprietary ATI drivers get ported (just like the Nvidia one was), they'll be big pieces of kernel panicking crap (just like the Nvidia one is).

Re:Unfree

[Anonymous Coward]

Same here... Matrox G550, 100% open source drivers. I chose it when I upgraded my machine about 3 years ago *because* it was well supplied with open source drivers... I specifically avoided Nvidia. Just recently I've been fucked over by Red Hat when they shipped FC4 knowing that X would not work on Matrox cards and now that this new fancy XGL system won't work either -- despite the fact that the G550 is perfectly capable of shoving plenty of polygons and textures around, even of it isn't state of the art.

This Just in

[coolGuyZak]

I gotta admit, I...just don't care. I haven't seen a google post today. Wake me up when there is one.

There hasn't been a Google article posted today! Somebody put that up on the front page!!

*thinks* but... then Google would be on the front page... damn paradox.

Re:This Just in

[kfg]

There hasn't been a Google article posted today!

And only old people in Korea still care about SCO.

KFG

How do they know they are fixed...

[Phariom]

"Compared to the xserver module code in freedesktop CVS a lot have changed. The new code contains an uncounted number of bug fixes, some major restructuring and a few additional features."

...if they didn't count them?

Re:How do they know they are fixed...

[Anonymous Coward]

Maybe they don't assume the axiom of choice!

Not opened up

[Anonymous Coward]

To say the development of XGL opened up is to assume it was closed before, which is absolutely untrue.

Dave did major changes to XGL (as you can read in his post), and it's simply not possible to merge the code back while in the middle of a transition such as that. On top of that the X.org tree was pretty much frozen to allow the transition to modular X and the release of 7.0.

The "Novell closed XGL" conspiracy came from people with their own personal agenda against Novell (and Ximian).

Re:Not opened up

[Anonymous Coward]

"To say the development of XGL opened up is to assume it was closed before, which is absolutely untrue."

No, it isn't as you point out in your very own post. Novel did a lot of changes and they were not publicly available, which is simply ineffective.

"Dave did major changes to XGL (as you can read in his post), and it's simply not possible to merge the code back while in the middle of a transition such as that."

Hello strawman argument.
While it might be true that merging the code back wouldn't have been possible, this of course doesn't mean that the code had to be non-accessible to outside developers. Nobody said Novel should merge them back into the main tree now, people just wanted to have access to the code, which is an entirely different thing.

"The "Novell closed XGL" conspiracy came from people with their own personal agenda against Novell (and Ximian)."

LOL, talk about conspiracy theories. Aaron Seigo simply pointed out why he thought the way Novell was developing XGL was wrong and guess what, I'm pretty sure Aaron's post lead to XGL development being opened up now, which is a good thing for all involved.

Re:Not opened up

[10Ghz]

Well, they DID close the developement. Was the work done in public? No. Could people outside Novell watch as things progressed? No. Could people outside Novell test XGL? No. Could people outside Novell submit patches? No.

In my book that means that the developement was closed. No-one except the company developing the software had access to it.

Dave did major changes to XGL (as you can read in his post), and it's simply not possible to merge the code back while in the middle of a transition such as that. On top of that the X.org tree was pretty much frozen to allow the transition to modular X and the release of 7.0.

So what? Are any of those a valid reason for their "we don't want any outsiders poking at our code!"-attitude? Even though X.org was frozen, and even if there were major transitions going on, there was no real reason to close the developement of XGL. Will we get better XGL because Novell decided to go at it alone? I doubt it. I really, really doubt it. Open source process has proven it's excellence over and over again, why would this case be an exception? Or is this a Good Thing (tm) because Nat Friedman decided that "Hey, why don't we try closing the developement, instead of doing this open-source-thingy?". Where is the benefit?

Re:Not opened up

[Anonymous Coward]

By your definition, all free software is done in a close development model. And it's true, it is; the source isn't released until the developer gets it to a point where it can be released. At that point, other people usually enter the development cycle. Not to mention the XGL development tree had absolutely no contributors for months, so a fork wasn't created.

In this particular case, the KDE developer didn't contact the XGL developer in private to address his concerns. Instead, he chose to voice them in a public forum first, which is childish. Had he contacted Dave the lengthy discussions about the subject in public forums would have been avoided. You can't possibly believe that starting a flamewar is the best way to go about things when a simple e-mail exchange can clear the matters.

What makes this whole situation even more sad is that some people believe this code is only being released because a flamewar was started, and that's absolutely not true. Novell is doing work on free software and they're not even getting credit for it; instead of saying "Thanks Novell" people are saying "Well, Novell was trying to be bad boys. Thanks you Aaron!". And what has Aaron contributed to XGL? Zero, nada.

Aaron also ignored that since Novell bought SuSE and Ximian they have only turned proprietary software (like YaST and evolution-exchange) into free software. There were no reasons for believing that Novell would turn XGL into proprietary software, quite the contrary.

Anyway, I don't see how Nat has anything to do with this subject. It's about Novell paying someone to do work on XGL and Aaron Seigo complaining about it in public.

Re:Not opened up

[Anonymous Coward]

By your definition, all free software is done in a close development model. And it's true, it is; the source isn't released until the developer gets it to a point where it can be released.

You can check out the "unreleased code" from the CVS of an open source project like KDE or GNOME or X.org. You couldn't do that with XGL.

Not to mention the XGL development tree had absolutely no contributors for months, so a fork wasn't created.

God forbid that during the time that Novell's development of XGL was closed, someone would want to contribute but not do so because they knew that doing so would be wasted effort because they had no current code to work against. Your argument is circular because the very fact that Novell had closed up would have a chilling effect on contributions by others.

In this particular case, the KDE developer didn't contact the XGL developer in private to address his concerns. Instead, he chose to voice them in a public forum first, which is childish. Had he contacted Dave the lengthy discussions about the subject in public forums would have been avoided. You can't possibly believe that starting a flamewar is the best way to go about things when a simple e-mail exchange can clear the matters.

This is a community effort and things should be in the open. The only flamewars that start are because of people like you who appear to have difficulty with discussing matters openly, and people like you who call someone like aseigo "childish" because you disagree with him. Flamewars don't start when you actually refute points with reasoned, factual argument and without name-calling.

What makes this whole situation even more sad is that some people believe this code is only being released because a flamewar was started, and that's absolutely not true.

How is it not true? It just happend, although any flamewar was tangential to the issues raised.

Novell is doing work on free software and they're not even getting credit for it; instead of saying "Thanks Novell" people are saying "Well, Novell was trying to be bad boys. Thanks you Aaron!".

They aren't helping free software by closing up the development of important pieces of free software architecture. This isn't about thanking Novell for working on XGL, which I'm very thankful for them doing so, but instead about the manner with which they were working on XGL. A manner which was in fact hindering free software despite Novell's contribution.

And what has Aaron contributed to XGL? Zero, nada.

He just got it opened up by being brave enough to talk about important issues despite the fact that people like you would attack him for doing so. What did you do to help the right thing happen with the development of XGL? Oh, you called aseigo childish.

Aaron also ignored that since Novell bought SuSE and Ximian they have only turned proprietary software (like YaST and evolution-exchange) into free software.

aseigo didn't say anything about those. He talked about XGL. Maybe he didn't want to cloud his argument with a red herring? The matter at hand wasn't the development of YaST or other projects, it was the development of XGL.

There were no reasons for believing that Novell would turn XGL into proprietary software, quite the contrary.

There was a reason for believing that XGL would be developed like proprietry software. That reason was that Novell was in fact developing XGL like proprietry software. Closing up the development so that only in-house people can work on it is the contrary of helping free software.

It's about Novell paying someone to do work on XGL and Aaron Seigo complaining about it in public.

Really? I thought that it was about Novell paying people to develop XGL without sharing the development with the public, and aseigo stating in his blog the reasons why he thought it was better to share the work being done on XGL with the public.

Re:Not opened up

[furanku]

Read for yourself: http://lists.osdl.org/pipermail/desktop_architects /2005-December/000629.html According to Nat himself there was obviously no need to close the devlopment: "For the first 10 or 12 months of development, there was no material outside contribution to Xgl." But: "We'd like to make a splash with something that is largely functional." That's maybe OK for a company and it's marketing needs, but not how open source development works. Although Novell sposored a lot of work on XGL it's not "thier" project. Everyone would have also appreciated Daves work if he'ld submitted to the open repository. I think esp. the Ximian crew behave in my opinion quite reckless und unfair. Remember all that Qt license bashing in the beginning, then all these "standards" for all desktops defined by gnome developers like tango, the fluffed gnome coup some weeks ago, Linus rant against gnome (a few days befor was that desktop meeting at OSDL in Portland, take a look at Nats blog, where just he says something like need to says something about that later in a short blog...) and the general "WE are the corporate desktop" attitude of the Gnome Marketing. And all this with a gnome that has serious problems with unmaintainable libraries which are full of double implemented technoligies and remains of wrong descions mage earlier like Corba, bonobo, ... Sun already dropped thier gnome based Java desktop, Slackware did so because of the unmaintanable librarie dependencies. So with all that background I would say developing XGL behind closed doors is not a "conspiracy" and the link to the discussion above is not a flamewar, but another Nat Friedman stupidity. And surprise, surprise, a few days after that discussion it looks like Dave accepted that this was silly thing to do and released his work on the mailing list: http://lists.freedesktop.org/archives/xorg/2006-Ja nuary/011922.html but it looks like it's to late and some people also started to work beside Dave on XGL and it seems like we most likely now will have a fork. So, Thank you, Novell, well done :(

mirror

[madpiggy_dj]

just the article, not the file(i can if you like) http://www.thebesttrek.net/forum/index.php?topic=3 41.0

Another reason to care ...

[JoeBuck]

.. is that future video cards might well be 3D-only, and the old 2D interfaces that X relies on won't be available. You'll have cards designed pretty tightly around the OpenGL spec and related specs, and if you don't have a way to do X with such a beast, forget using the card with Linux.

Re:Another reason to care ...

[Kjella]

.. is that future video cards might well be 3D-only, and the old 2D interfaces that X relies on won't be available.

...and x86 will be replaced by RISC-instructions. Perhaps internally on the chip 2D will be nothing more than translation to 3D instructions, but I'm willing to bet they'll be available for decades. I imagine the circuitry would make up <<1% of the transistors.

Re:Another reason to care ...

[Bazzalisk]

Yep, and new PCs don't ship with paralel ports ...

XGL is...

[CarpetShark]

The point of XGL is to take the 3D engine in most graphics cards and use it as the basis for X's acceleration.

Before, the 2D acceleration engine was used, but 2D has fallen behind in terms of performance, and 3D can do everything 2D can do, plus more. XGL uses OpenGL to render bitmaps, as well as to render video, composite alpha-channeled windows, rotate and deform windows, etc. I think font antialiasing will benefit, via a (potentially) faster XRender implementation. I gather it's also integrated with glitz already, which means that vector graphics like SVG and scalable icons, buttons, widget themes, etc. will also be done via OpenGL.

The one remaining gap (that I know of) is hardware support. The Novell guy releasing this (sorry, I forget his name right now) seems to say that it works with relatively minor changes on Free Software DRI drivers. I know that was always an intention, at least. So, hopefully, we'll see more drivers trying to support DRI as base level of driver compliance, rather than as an afterthought. The X desktop will be faster, smoother, and more featureful... so long as desktop developers don't go overboard and expects everyone to have next-generation 3D engine performance just to run a wordprocessor ;)

All in all, a very good thing :)

Re:XGL is...

[MichaelSmith]

desktop developers don't go overboard and expects everyone to have next-generation 3D engine performance just to run a wordprocessor

I recently built a news office system for my wife to use. I bought a new video card, the cheapest AGP card I could find. It is called an HIS Excalibur 3D graphics card, with the slogan "Power up, Gamers!", which I know is rubbish. It is a cheap, generic card.

Interestingly this card has two video outputs. I wonder if I can get XCinerama working on it...

Re:XGL is...

[kimvette]

Hmm, Apple seems to get great performance out of lowly Rage128 cards in OS/X, so why can't the x.org team do the same on later-generation hardware? Also, why MUST I have a shared framebuffer for 3D support? When I want to run OpenGL apps (or at least run them in a stable environment) I need to restart X in a single head configuration. :( It should be able to support acceleration on multiple video cards - or at bare minimum accelerate the primary display and not break when I run a 3D app with Xinerama enabled. It should at worst case handle the situation gracefully - trap any errors and display a dialog scolding me, or ideally, move the app to the primary accelerated display (assuming they can achieve that).

This is a HUGE negative for X.org relative to OS/X or even Windows.

Re:XGL is...

[CarpetShark]

Yep, I'm actually using one of those lowly Rage128's in a G3 laptop running KDE. It does everything I need fine so far. But, part of what I "need" is the latest KDE, so I'll really feel it if KDE 4 is less responsive rather than more, as been promised :) I wasn't aware of the multi-headed OpenGL issues, although I knew multihead did have some issues. Sad, considering that multihead basically seems to have started on X :(

Re:XGL is...

[electrichamster]

s/XCinerama/Xinerama/

:-P

Re:XGL is...

[MichaelSmith]

I knew it was something like that. Thanks.

Does it matter?

[Stalyn]

Does the source open during development matter? Look how much David Reveman got done by himself "behind closed doors". Really what matters is the source is available upon release to the public. Before that it doesn't really matter. The truth is the majority of the Xorg community doesn't believe in an OpenGL accelerated desktop. Look at the mailing list. The only people who do are a small group of coders who most likely do not have the time to actually achieve something worth using.

However if a company like Novell did pick up the project and paid developers to work on it full time but the source would be closed until release... well tough luck. In reality the only reason David released the code now was to get it into the Xorg tree. That way they can continue to "code-drop" to a tree that can be used by everyone, instead of kdrive which is for developers.

Also the Xorg developers seem to be concerned with Xegl which David isn't even working on. I dont care either way. Just get it done.

Re:Does it matter?

[Kjella]

Does the source open during development matter? Look how much David Reveman got done by himself "behind closed doors". Really what matters is the source is available upon release to the public.

Perhaps I'm just being a cynical bastard, but even if he doesn't accept a single patch I prefer the code to be publicly available. There's been at least a few incidents where OSS developers have spent a lot of time, usually delaying for more than a normal release and then pull a bait-and-switch and close the source, leaving the community at least a few normal releases behind without warning. Not that I really mind (those that can, are those that own all the source), but I wish they'd be honest and up front about it. Continous code release as the norm is the best way to ensure this.

Re:Does it matter?

[Anonymous Coward]

Two things:

1. XGL wasn't developed in-house for Novell.

XGL was started by independent free software programmers. Novell highered some of them and then took the developement 'in-house'.

It started off open, Novell paid some of them to concentrate on it on the 'inside', now they are openning it up again.

2. You don't understand the relationship between Xegl and XGL.

XGL is a _toy_, it's a pre-view. It's a beginning. It's forming the basis for future X servers, but it is not actually usefull itself.

XGL requires another X server to run on. Similar to Xnest.

Xegl is based on XGL (again started and worked on originally without any Novell involvement), it is a standalone X server that will actually be used.

You see one is useless without the other. XGL is worthless outside of developement. Xegl is worthless without the basis.

Xegl is called Xegl because it takes OpenGL and add the EGL extensions to it. These extensions were originally designed for embedded work, but can be used with a full-fledged OpenGL system like Linux has. What it does is allow OpenGL programs to send signals to change screen resolution and things like that. These extensions will 'fill out' the OpenGL API so that you can use it effectively for a basis of a standalone system.

Originally Linux's OpenGL stuff was like this. With original Mesa solo you didn't use X to run 3d accelerated applications. With things like GLX (open sourced from SGI) to 'mix' or manage OpenGL applications on a X server.

There still are some gaps though.. Indirect rendering isn't very hot, for instance. That is when you run a application remotely (X Windows is a networking protocol after all, like HTTP or whatnot) you can't get OpenGL acceleration working on it.

This, combined with other advances such as 'Modular X', 'X Damage', 'X composite', and 'XGL'/'xegl', is helping to move the X system from the 1980's era technology (were it is now) to the 2010's technology (where it will be in a couple more years).

Hopefully it will allow you to do things like display your desktop applications on your laptop or handheld (which it can do now) but also allow you to easily transfer applications between devices while they are running, and to display to display. All with nice acceleration with complex window managers. Oh and don't forget Vector-based graphics (which we will have with next releases of Gnome and KDE), which will be OpenGL themselves accelerated in a year or two.

EXA will help this a bit.

As X server switch over to EXA for the time being and applications utilize it's acceleration more and more.. this EXA stuff translates suprisingly well to OpenGL.

Also it will have the added benifit of moving X off of the hardware.

Right now with X.org's X server you have all this extra crap it has to do with hardware drivers and such. By moving to pure OpenGL then each OS can handle the protocol stack on themselves. You can have Linux framebuffer with Mesa-based DRI drivers, propriatory drivers or have software Mesa on Netbsd, some sort of weird embedded stuff, or have Window's OpenGL stuff.. It doesn't matter. Let the OS manage the hardware itself and run X windows on OpenGL, just like any other OpenGL application.

Right now we have Framebuffer, DRI, VGAcon, EXA and such that all have to fight over the hardware at the same time.

That's 4 independant drivers from multiple independant vendors.. some from DRI, some from Linux kernel, some from X.org, that all have to use the _same_peice_of_fucking_hardware.

Think about this:
1 peice of hardware, 4 drivers.

How many devices do you expect to function properly like that?

With OpenGL-based X server, then you have only one driver that can do everything. It can even do console if you want.. (although I don't expect Linux to drop vgacon as long as video cards support legacy vga mode)

Also if your a disapointed programmer wanting to work on X then I suggest you look strongly at XCB.

Re:Does it matter?

[Stalyn]

XGL was started by Dave Reveman. Actually all XGL code including Xegl starts with, "Copyright 2004 David Reveman". Also it might have been true XGL was a 'toy' in August but alot has changed. However it is true you still need an X server to run XGL on top of it, this might be changing.

However I do agree Xegl is probably the better solution but the project has had little work on it done since Jon Smirl left.

Re:Does it matter?

[Anonymous Coward]

Dave Reveman was hired by Novell because of his work on XGL.. not to create it. He is not the only one that has been hired to work on XGL because of previous experiance with it.

It's just to bad that they didn't hire more XGL/XeGL hackers. Some of them have been left out in the cold.

He is also the major guy behind Glitz, which is the OpenGL backend for Cairo vector based graphics.

In fact Glitz goes hand in hand with XGL.

He is absolutely wonderfull guy and a good programmer to boot. But Novell isn't responsable for this creation.. mainly because Dave did the initial work on his own!

Re:Does it matter?

[Stalyn]

I never said Novell created XGL.

However if a company like Novell did pick up the project

Anyway, it would have been nice if someone gave credit to Jon Smirl instead of revoking his CVS access and basically making him an outcast. I guess he did it to himself though, one major flaw of open source is the bullshit politics. Thats why I favor a closed-source developement process for the time being. Honestly if Novell is paying developers to work on XGL, they will do 10x the work than unpaid ones. In the long run I just want the thing out there and working, if it means paying people to finish the project at the cost of open development... so be it.

Re:Does it matter?

[octopus72]

There still are some gaps though.. Indirect rendering isn't very hot, for instance. That is when you run a application remotely (X Windows is a networking protocol after all, like HTTP or whatnot) you can't get OpenGL acceleration working on it.

This is about to change with XGL. Because X server is itself a GL application, it will render all child indirect-GL windows in it's own context, hardware accelerated.

Re:Does it matter?

[Anonymous Coward]

I like how a post that is incorrect on so many points gets modded up informative. Good work mods!

Yay for Complaining!

[poofyhairguy82]

I am glad to see that development opened a little. Not because I think it will speed the process up, but because I want to compile and use the newest Xgl! I am an Eye Candy addict.

Hopefully this WILL make development more transparant. The Xgl is needed for the future Linux desktop and I am glad Novell decided to play ball with everyone.

Oh course, the Xgl is still YEARS away from being shipped as the default on the desktop of a major distro. But we have to start somewhere, and people like me need the new eye candy fix!

Re:Yay for Complaining!

[Webmonger]

Hopefully this WILL make development more transparant.

From what I hear, not only will it be more transparent, but it will have smooth, alpha-blended shadows.

Sorry, couldn't resist. :-)

Just So You Know

[poofyhairguy82]

In a very real way, for a number of people, Vista's compositing stuff works now, too. In fact, I'd not be at all surprised if there were comparable numbers of people running the Vista/WPF betas and XGL.

Just in case you did not know, there is a way to get (mostly) stable composite effects in Linux without Xgl.

I use Xcompmgr daily with no problems since the last Nvidia driver.

Reality check

[Anonymous Coward]

R100 was released in Summer 2000
R200 was released in Summer 2001
R300 was released in Summer 2002

We are now living in 2006 and you saying that opensource drivers work in SOME cases and are fast in SOME cases...

"The simple fact is that the very thing you're saying is impossible - opensource developement of top-quality drivers - has already happened."

Ok, let's put in that way: opensource developement of top-quality drivers is impossible within a reasonable timeframe (before the hardware becomes obsolete).

Currently ATIs best chip is R520, which uses vastly different architecture than R300. During this year ATI will release R600 which will use unified shader architecture, which is again completely different. I'm 100% sure that we won't have even half-decent opensource drivers for R520 before R600 becomes available.

what license is this code under?

[Anonymous Coward]

What license is this code under? What are its benefits and disadvantages? Does it allow one to take it closed source?

But OpenGL is nearly crippled by the X protocol.

[master_p]

The greatest use of accelerated 3d graphics would be the independence of the GUI display from the physical screen resolution without loss of detail (resolution permitting, of course). But the X protocol is pixel-based, and therefore OpenGL is almost useless. Windows can be treated like textures, but GUIs would be much better if they were vector-based.

Why linux?

[octopus72]

Why is this report published as a Linux story on Slashdot? XGL's goal is to be prefectly capable of running on other Unix systems (BSD's, Solaris), either layered on top of existing X server or using DRI+MESA-solo (or proprietary hardware GL implementetation), as well as on MacOSX and Windows GL stacks. There is even a possibility of support on embedded OGL-ES systems.

Eyecandy video

[ion_]

Here's a video maciek at #xorg captured and i'm seeding:

glxcompmgr effects (3.9 MiB)

OpenGL in Windows

[oddityfds]

Do they trust that Windows will continue to have good OpenGL support? Maybe it won't.

Re:But OpenGL is nearly crippled by the X protocol

[CarpetShark]

Agreed. I tried to implement something like this back in my Amiga days. Truly resolution-independant graphics are well overdue.

However, I'd also like to see the 3D engine (and other specialised chips like audio DSPs etc.) becoming more like standard system resources, used as an when possible, for whatever they can be used for. This idea of having specialised chips that just sit there unless something needs to be drawn, while the CPU simulates a weather system is a bit wasteful.

IT HURTS MAKE IT STOP

[Hard_Code]

"So don't worry about that."

That's sort of hard in this alphabet soup of acronyms for myriad projects and libraries.

I really really hope, and hope somebody can confirm this, that at the end of the day there is a STRONG inclination to:

* developer a SINGLE (SINGLE! (SINGLE!! (i mean it))) X server binary which can either render through hardware acceleration OR software, which can be determined dynamically at startup (through configuration or auto-detection), as well as the slew of other acronyms. A separate standalone OpenGL-only X server would be a configuration, maintenance and end-user documentation nightmare.

All this stuff sounds really really cool, but it all appears very fragmented, with each fragment dependent on some other alpha-quality fragment that has not yet been merged into anything other than a nice dream.

So I really hope all these exciting fragments get unified under a consistent X server and set of modules/libraries, instead of remaining really enticing fragments forever.

Re:But OpenGL is nearly crippled by the X protocol

[master_p]

Indeed. I was an Amiga user too, so I can understand your rationale. Every computer needs specialized chips for the most difficult tasks that are repeated inside a program...array math is one of those tasks, and the Pentium-class CPUs are supposed to have it, but they nowhere near reach the performance of those chips inside GPUs.

ATI's Driver Crashes Constantly

[Flammon]

Don't bother buying an ATI card if you plan on using their driver for any GL work. Your box will lock up hard. Constantly. You won't be able to play UT2004 for more than 30 minutes on a good day.

After 2 years of fighthing with the crappy ATI drivers and my Radeon 9000 I finally gave up and bought an Nvidia. It's been three months since the purchase and my system has not locked up once. It is rock solid. I put the Radeon 9000 in the kids computer which runs Windows XP and it's much more stable there so I know that there is nothing wrong with the card. The ATI provided Linux drivers are just horrible.

Re:ATI's Driver Crashes Constantly

[nzhavok]

I've also found the drivers to be unstable (playing Neverwinter Nights, never tried UT) and a load of trouble. My last two laptops have both had ATI cards, the first a radeon 9000, and my current a FireGL2 (really a radeon 9600).

Really I had no choice since I had already decided to by a thinkpad, and they only came with ATI cards or integrated graphics. I just boot to windows to play games so that's no problem, but I really find X sluggish without the hardware acceleration. The propriatary ATI drivers for linux don't play nice with hibernate/suspend whiuch sucks, and also didn't work with the xrender extensions when I tried them.

I probably won't buy a thinkpad next time mostly due to the non-existant support to connect it to my monitor via DVI (this is really awful, and the VGA connecter has very bad quality!), and the fact that I find myself using linux more often and they still have ATI cards.

The main problem I face is that I don't trust the build quality of the majority of laptops these days. I have used many brands and so far the only quality ones I have used are the T model IBMs and the G4 Powerbooks from Apple. The IBMs lack simple simple things (like DVI support) and use older components, but have an excellent build quality and feel. The powerbooks seem good (I have never owned one only used them) but I can't play my windows games, so they are out. Hopefully the mactel will be able to run windows and linux, and if the build quality is closer to the G4 rather than the G3 that will probably be my next choice.

Re:huh? - Not XGL

[UnderScan]

That video is not XGL. It is quite impressive and it can give you an idea of what XGL could look like, it is not XGL but is Luminocity and it is taken from http://www.gnome.org/~seth/blog/xshots. Read "How Luminocity Relates to Other Stuff" to get more info on Luminocity. Read the interview with KDE's Zack Rusin: "Beauty and Magic for KDE, with Zack Rusin". Download the demo video of Zack's XGL hacks: http://vizzzion.org/stuff/xgl_wanking.avi 16MB. If you want to read more about XGL then read aseigo's blog entry or Zack's blog.