Let The Battle Commence
AIGLX is very, very interesting. I think this is a superior solution to the current Novell hack-fest (Xegl is where the love is but that doesn't work at all, and Xglx is just so sick) that I'm very interested in having a play with this.
As Mallum said, the Great 2006 Novell vs Red Hat War Of The Eye Candy has started. The the battle commence!
NP: Songs In The Key Of Life (disc 2, Stevie Wonder
Posted by Anon at Mon Feb 20 18:13:28 2006:
You're completely wrong. The fact that Xgl+Compiz development model wasn't done right does not imply that this is the right path to follow, sorry.
Wasting time in such outrageous hacks as AIGLX is just that, wasting time. In no way this architecture will be able to be more than another hack.
Admittely Xgl is a hack too, and Xegl is slowly coming, but this is one of the very few situations that having a "legacy free" design and rewrite makes sense.
Posted by Anon at Mon Feb 20 18:19:47 2006:
Wasting time in such outrageous hacks as AIGLX is just that, wasting time. In no way this architecture will be able to be more than another hack.
Admittely Xgl is a hack too, and Xegl is slowly coming, but this is one of the very few situations that having a "legacy free" design and rewrite makes sense.
Ok, I also forgot that nvidia supports AIGLX because is more friendly to their current closed source development that a Xegl solution would be.
Posted by Ross at Mon Feb 20 18:25:00 2006:
Anon: who said anything about my gripes with Xgl being about the development model? All of the source is in CVS now.
Xglx is a hack, no doubt about that. Xegl is a very interesting idea for a server but requires large amounts of work. AIGLX simply accelerates indirect rendering, and as such is a simplier implementation and when a composite manager is not running, there same old code is being used.
I look forward to the day when Xegl works perfectly, but for now I think AIGLX will be more stable and a far cleaner model than Xglx.
Posted by Jamie McCracken at Mon Feb 20 18:25:01 2006:
Xglx is a hack, no doubt about that. Xegl is a very interesting idea for a server but requires large amounts of work. AIGLX simply accelerates indirect rendering, and as such is a simplier implementation and when a composite manager is not running, there same old code is being used.
I look forward to the day when Xegl works perfectly, but for now I think AIGLX will be more stable and a far cleaner model than Xglx.
This is turning into an amusing power struggle between Red hat and Novell over who rules the desktop.
I had been thinking that Novell was starting to get the upper hand what with Fedora including mono and now XGL taking the limelight away from everything else.
This could go either way but my money is on Red Hat as they appear to have widespread support from the xorg developers. What they are doing is also less radical and so might be a better solution?
That said, at the end of the day all I care about is having a stable accelerated desktop so I will take whichever one wins here.
Posted by Chris Lord at Mon Feb 20 18:48:20 2006:
I had been thinking that Novell was starting to get the upper hand what with Fedora including mono and now XGL taking the limelight away from everything else.
This could go either way but my money is on Red Hat as they appear to have widespread support from the xorg developers. What they are doing is also less radical and so might be a better solution?
That said, at the end of the day all I care about is having a stable accelerated desktop so I will take whichever one wins here.
Really, how much less of a hack is this than Xgl? It requires a modified mesa library, modifications to applications and apparently new X extensions? (this is what the site seems to imply, am probably wrong :))
I'll side with Xgl on this one - it may be a tremendous hack, but it's a tremendous hack that works with existing technology and seems pretty stable (been running it on my computer for a couple of days solid now, it's certainly about as stable as anything else :)). When AIGLX can sport the same stability and niceness as Xgl, I'll change my mind (although given that Xorg with just composite on its own is very unstable for me, I imagine this'll be a while)
Posted by Anon at Mon Feb 20 18:52:33 2006:
I'll side with Xgl on this one - it may be a tremendous hack, but it's a tremendous hack that works with existing technology and seems pretty stable (been running it on my computer for a couple of days solid now, it's certainly about as stable as anything else :)). When AIGLX can sport the same stability and niceness as Xgl, I'll change my mind (although given that Xorg with just composite on its own is very unstable for me, I imagine this'll be a while)
1.- The fact that Xgl et al haven't got enough peer review is almost undeniable. This is due to closed development, which has actually hurt the quality and future adoption of this technology.
2.- If you read the nvidia white papers, all of their reasoning for supporting AIGLX is based on keeping legacy support. This is not good as it will result in a clumsier Xserver. I think that legacy support should be kept in the old Xserver. This way a user can choose either server depending on the hardware used. I'd say this is an attempt to build a one-size fits all solution.
3.- I think the only significant problem that a full OGL Xserver poses is the need to adopt a fixed set of OGL support, let's say OGL2.0.
4.- So the whole point becomes a struggle between a better technical solution against a more convenient one. And this is usually where open source shines, because it doesn't have the constraints that traditional closed source vendors have. I mean, MS can't go and throw away all the Win32 API in Vista, they have to support it, which becomes a huge hurdle. The point is that for a hardware vendor like nvidia the easy path is to add more and more bloat the whole thing, as it's custom in the closed source world. Otherwise it would mean to completely redesign their OGL driver.
5.- Will Xorg adopt the painful but technical sound solution or the patchy one?
Regards
Posted by Ross at Mon Feb 20 21:19:08 2006:
2.- If you read the nvidia white papers, all of their reasoning for supporting AIGLX is based on keeping legacy support. This is not good as it will result in a clumsier Xserver. I think that legacy support should be kept in the old Xserver. This way a user can choose either server depending on the hardware used. I'd say this is an attempt to build a one-size fits all solution.
3.- I think the only significant problem that a full OGL Xserver poses is the need to adopt a fixed set of OGL support, let's say OGL2.0.
4.- So the whole point becomes a struggle between a better technical solution against a more convenient one. And this is usually where open source shines, because it doesn't have the constraints that traditional closed source vendors have. I mean, MS can't go and throw away all the Win32 API in Vista, they have to support it, which becomes a huge hurdle. The point is that for a hardware vendor like nvidia the easy path is to add more and more bloat the whole thing, as it's custom in the closed source world. Otherwise it would mean to completely redesign their OGL driver.
5.- Will Xorg adopt the painful but technical sound solution or the patchy one?
Regards
1) peer review is coming. Yay Novell for releasing the patches, and yay the other non-paid Xorg developers for taking the time to merge it.
2) I presume nVidia like AIGLX as it means they don't need to do any more work (the same GLX extension is used by Xglx and AIGLX). Support Xegl would require writing an EGL driver, which is non-trivial. I've no problem in calling nVidia lazy here, as I'm 99% sure they already have EGL drivers for the mobile/embedded chips.
4) We can have both of course: I believe that AIGLX will be more reliable quicker as its a simplier design than Xglx, yet over time when there are EGL drivers available for common chips Xegl will mature and be a viable alternative. Then people can chose between a GL-when-they-want-it server, or a pure-GL server.
5) both, considering they are both in Xorg CVS. They are not mutually exclusive.
Posted by John (J5) Palmieri at Mon Feb 20 22:12:02 2006:
2) I presume nVidia like AIGLX as it means they don't need to do any more work (the same GLX extension is used by Xglx and AIGLX). Support Xegl would require writing an EGL driver, which is non-trivial. I've no problem in calling nVidia lazy here, as I'm 99% sure they already have EGL drivers for the mobile/embedded chips.
4) We can have both of course: I believe that AIGLX will be more reliable quicker as its a simplier design than Xglx, yet over time when there are EGL drivers available for common chips Xegl will mature and be a viable alternative. Then people can chose between a GL-when-they-want-it server, or a pure-GL server.
5) both, considering they are both in Xorg CVS. They are not mutually exclusive.
* Sigh *
People really do like drama. Xgl and AIGLX are not about Novell vs. Red Hat. They are simply two different approaches to a similar problem. What people fail to see is you can run either, you can even mix and match with metacity or compiz. Take your pick, in the end it just means a better desktop experience for the user.
To those who think it is a waste of time the question is how much of your time have you contributed to productive solutions?
Posted by Anonymous Coward at Tue Feb 21 06:14:28 2006:
People really do like drama. Xgl and AIGLX are not about Novell vs. Red Hat. They are simply two different approaches to a similar problem. What people fail to see is you can run either, you can even mix and match with metacity or compiz. Take your pick, in the end it just means a better desktop experience for the user.
To those who think it is a waste of time the question is how much of your time have you contributed to productive solutions?
Xgl seems to be the better solution even though it is a glorified hack. To have one software layer to do all the rendering would be the best way to do things. However AIGLX is going to be the short-term solution and most likely get adopted the quickest.
Also I'm not sure about the future of Xegl, it didn't help when the only active developer quit the project and was basically run out of town by his fellow Xorg developers.
What's this about peer review? The only people who really understand Xgl is David Reveman and himself.
Posted by Arne at Tue Feb 21 07:55:00 2006:
Also I'm not sure about the future of Xegl, it didn't help when the only active developer quit the project and was basically run out of town by his fellow Xorg developers.
What's this about peer review? The only people who really understand Xgl is David Reveman and himself.
I think the main show stopper for an accelerated OSS desktop is the non-availability of OSS hardware or oven good quality OSS graphics drivers.
RedHat, Novel and Canonical ( and HP, IBM? ) should think about joint forces to produce a reliable hardware platform for Linux just like Apple has a reliable HW platform for MacOS. This would give a solid base to show what is possible on good hardware and give a certain force to other vendors to produce better ( or OSS ) drivers for their own products too.
I do not think the ultimate desktop experience will help much when it only works on 10% of all hardware and the other 90% will struggle with anything from simply unaccelerated to inacceptable crashes and inconvenience.
RedHat, Novel and Canonical ( and HP, IBM? ) should think about joint forces to produce a reliable hardware platform for Linux just like Apple has a reliable HW platform for MacOS. This would give a solid base to show what is possible on good hardware and give a certain force to other vendors to produce better ( or OSS ) drivers for their own products too.
I do not think the ultimate desktop experience will help much when it only works on 10% of all hardware and the other 90% will struggle with anything from simply unaccelerated to inacceptable crashes and inconvenience.
