Slashdot Mirror
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."
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.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
How will this impact the development of XEGL?
The theory of relativity doesn't work right in Arkansas.
Can anyone translate this into English? What is XGL and why should we care?
Find free books.
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?
Don't blame me, I didn't vote for either of them!
http://live.gnome.org/Luminocity
There. Fixed that link for you.
There are 11 types of people. Those who understand binary, those who don't and those who are sick of this lame joke.
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.
"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?
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).
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
Spooooon!!!!!
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.
Game! - Where the stick is mightier than the sword!
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.
Open Source Sushi
.. 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.
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 :)
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.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
No, we shan't.
There are 11 types of people in the world: those who can count in binary, and those who can't.
This has nothing to do with games. Read the article.
Vandemar.org
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.)
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!
Open Source Sushi
VISTA DOESN'T EXIST YET!
In contrast, nVidia drivers and composite work now.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
XGL is about rendering a 2D desktop using OpenGL
Thanks for the explanation. They should've made that part of the summary.
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.
It's official. Most of you are morons.
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.
Open Source Sushi
Indeed. Vista doesn't exist yet, and basically everybody by now has heard about how they're crippling OpenGL in it...
Karma: It's all a bunch of tree-huggin' hippy crap!
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.
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?
The Farewell Tour II
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.
that would be spelling out the joke for the hard of understanding.
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 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.
Here's a video maciek at #xorg captured and i'm seeding:
glxcompmgr effects (3.9 MiB)
Thanks for such an informative post. If only this information was actually present in the Xorg documentation!
Do they trust that Windows will continue to have good OpenGL support? Maybe it won't.
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.
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.
"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.
It's 10 PM. Do you know if you're un-American?
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.
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.
ayottesoftware.com
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.
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.
Game! - Where the stick is mightier than the sword!
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.