Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [News] XOrg Gets New Acceleration architecture: Glucose

__/ [ [H]omer ] on Wednesday 16 August 2006 16:24 \__

> Roy Schestowitz wrote:
>> __/ [ [H]omer ] on Wednesday 16 August 2006 14:29 \__
>>> Roy Schestowitz wrote:
> 
>>>> | - it's an OpenGL based acceleration architecture,
>>>> http://lists.freedesktop.org/archives/xorg/2006-August/017527.html
> 
>>> This is a very welcome, if predictable, step forward, particularly
>>> for Fedora, that favours aiglx over XGL.
>>>
>>> http://fedoraproject.org/wiki/RenderingProject/aiglx
> 
>> I believe that I initially heard of (read about) AIGLX in the
>> context of seminal work on Compiz/XGL. It was some project that took
>> place at Red Hat's labs at the time and was called Luminocity (sic).
> 
> As I understand it, aiglx is set to become an intrinsic part of X.org,
> whereas XGL is not, although things may well have changed since I last
> checked.
> 
> If this is (still) true, then XGL is likely to become depreciated
> eventually, unless the two projects merge, or Novell gets the better
> of Red Hat.
> 
> From the above Red Hat link:
> 
> "Although early work on XGL was done in the open, XGL spent the last
> few months of its development behind closed doors and was dropped on
> the community as a finished solution. Unfortunately, it wasn't peer
> reviewed during its development process, and its architecture doesn't
> sit well with a lot of people."
> 
> David Reveman's (Novell) rebuttal:
> 
> "An important goal with X on OpenGL is to make it easier for X to keep
> up with the advances in graphics hardware. Eliminating the custom 2D
> acceleration code will reduce the development burden and make this
> easier. This can probably be achieved through AIGLX as well, I know
> that the people working on AIGLX have discussed putting some of the
> acceleration code I have in Xgl inside Xorg with AIGLX and that would
> be a step in that direction. However, I strongly believe that going
> all the way to an X server completely on top of the OpenGL API is the
> best solution in the long run."
> 
> http://lists.freedesktop.org/archives/xorg/2006-February/013306.html
> 
> My personal opinion is that I *do* favour the XGL method, since it
> seems less driver dependent, and also because it it fully "here and
> now", but I still have some reservations over its earlier development,
> and of course, I still tend to side with Red Hat out of loyalty.
> 
> To be honest, I think Red Hat/Fedora are making a mistake not
> supporting XGL; it's virtually ready and thoroughly implementable, and
> the bandwagon is rolling fast.

Thanks for all the information. I learn so much in COLA and the ability to
interact is a big plus. *smile*

I am becoming a bit disappointed with Red Hat's attitude. Many could now
argue that Red Hat is cashing in on Linux while contributing too little
(BearItAll recently made this argument as well). To make matters worse, have
a look at the following, which is just one among _many_ articles noting this
observation.

http://www.crn.com.au/story.aspx?CIID=58337&src=site-marq

        Red Hat a no-show at LinuxWorld

Red Hat has got its own symposium/conference and this could get people
humming. I think there is still too little interaction. There is also
tension between Novell and Red Hat because they target the same niche as
clients swiftly go 'boing-boing' from one Linux vendor to another. The
exchanges of fire over "Xen is/isn't ready" is one example. Then again,
Debian and Canonical have some friction as well. Xen and VMWare were no
exception, until very recently (hypervisor standard). Let's hope that they
all find a way to get along. OSDL, the Portland project and SGL are intended
to bridge some gaps.

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index