Slashdot Log In
XGL Development Opens Up
Posted by
ScuttleMonkey
on Tue Jan 03, 2006 01:37 AM
from the prying-open-the-doors dept.
from the prying-open-the-doors dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Nice to see more openness. (Score:5, Insightful)
Re:Nice to see more openness. (Score:5, Insightful)
Parent
Re:Nice to see more openness. (Score:3, Insightful)
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. (Score:4, Insightful)
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...
Parent
Re:Nice to see more openness. (Score:4, Insightful)
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.
Parent
Re:Nice to see more openness. (Score:3, Insightful)
"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.
Re:Nice to see more openness. (Score:3, Insightful)
Re:Nice to see more openness. (Score:4, Informative)
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.
Parent
Re:Nice to see more openness. (Score:2)
XEGL (Score:2)
Re:XEGL (Score:2)
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.
huh? (Score:5, Interesting)
Re:huh? (Score:4, Informative)
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.
Parent
Re:huh? (Score:4, Informative)
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
Parent
XGL is... (Score:5, Informative)
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 :)
Parent
But OpenGL is nearly crippled by the X protocol. (Score:3, Insightful)
Re:huh? (Score:3, Informative)
Re:huh? (Score:5, Informative)
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).
Parent
Another reason to care ... (Score:5, Insightful)
Parent
Re:huh? (Score:5, Informative)
Parent
Re:huh? (Score:2)
Unfree (Score:4, Insightful)
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 (Score:5, Insightful)
Parent
Re:Unfree (Score:4, Informative)
And even better: Buy a card from the Open Graphics Project [kerneltrap.org] 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).
Parent
Re:Unfree (Score:5, Insightful)
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
Parent
Re:Unfree (Score:3, Interesting)
Re:Unfree (Score:2)
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 (Score:5, Informative)
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
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.
Parent
Re:Unfree (Score:4, Informative)
Really? Everything I read tells me that the crappy closed ATI drivers are still faster when it comes to 3D [thinkwiki.org] 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.
Parent
Re:Unfree (Score:4, Funny)
Parent
Re:Unfree (Score:4, Insightful)
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.
Parent
Re:Unfree (Score:3, Informative)
And FYI, the older Radeons (up to 8500 I believe?) have a decent open source driver.
Re:Unfree (Score:4, Insightful)
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.
Parent
Re:Unfree (Score:5, Informative)
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.
Parent
Re:Unfree (Score:3, Informative)
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 (Score:3)
How do they know they are fixed... (Score:4, Funny)
Not opened up (Score:3, Interesting)
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).
Does it matter? (Score:4, Interesting)
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? (Score:5, Informative)
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.
Parent
IT HURTS MAKE IT STOP (Score:3, Interesting)
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
Yay for Complaining! (Score:3, Interesting)
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:Luminocity (Score:3, Interesting)
There. Fixed that link for you.
Re:Luminocity (Score:3, Informative)
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 [ubuntu.com]. 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 t
This Just in (Score:2, Troll)
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:No Games Yet? (Score:5, Informative)
Parent
Re:No Games Yet? (Score:3, Informative)
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
Re:No Games Yet? (Score:2)
VISTA DOESN'T EXIST YET!
In contrast, nVidia drivers and composite work now.
Re:No Games Yet? (Score:5, Informative)
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.
Parent
Re:Yay CCDN (Score:2)