Xegl lives!

Jon Smirl jonsmirl at gmail.com
Tue May 24 16:22:11 PDT 2005


On 5/24/05, Stuart Kreitman <Stuart.Kreitman at sun.com> wrote:
> You're making an assumption that Sun has its head in the sand.  I think
> you're missing the point.

I have no clue what Sun is doing with graphics today but there have
definitely been times that Sun has its head in the sand. Of course
that can be said about a lot of companies. I've even had my head in
the sand at times.

> Similar to Alan's messages, we have existing constuents, and we are
> bringing our Solaris forward with Xorg, Mesa, x86, etc pretty rapidly.  
> The notion that hw GL shall be ubiquitous is tied to fat desktops.

There are shipping cell phones with hardware assisted GL. The switch
to GL is not so much about 3D as it is about using GL as a standard
interface for 2D acceleration of things like compositing.

Check out OpenGL-ES. There is a 100K proprietary implementation of it.
http://www.khronos.org/opengles/spec/
That's not fat at all. 

> Its replacing X-protocol bigotry with GL bigotry.

I haven't said anything about protocols. Depending on how you
configure it remote Cairo can draw with either X or GL protocols. No
one has benchmarked which is faster yet.

> At some line below that ( Sunray, ltsp, X-on-windows?) a lot of people
> are dead-ended. If you don't have an answer for them (and their developers), 
> you won't get their support.

Nobody is with withdrawing the current X server, but the industry
continues to move forward. I don't expect a Intel 286 based CPU to run
a composited desktop either.

> Jon, you and I had a long discussion in Feb about these kinds of
> tensions as they affect our ability to build the systems that you feel 
> are so obviously right to do.   If  you want to attract more developers
> to cooperate with your vision, focus more on motivating points and less 
> on deprecating or isolating ones.  I would like to see a migration path 
> that I can sign up to.

It is a fact that Windows and the Mac are moving to accelerated
composited GUIs. This will happen and there is nothing we can do about
it. These new accelerated composited GUIs have an obviously
differently look and feel that most people prefer.

Now we have to make some choices:
1) Does Linux/Solaris want to support a similar GUI?
2) What are the practical means of building the GUI?
3) How much backwards compatibility is needed?
4) What is the acceptable hardware spectrum?

Looking at how do you build it from a Linux perspective, the main
question is where does acceleration come from?

1) existing DRI GL drivers
2) extension of XAA
3) a new code base

To me the obvious choice is the existing DRI GL drivers. That choice
solved several problems.

1) It was already written
2) It is already full accelerated
3) the API is standardized, well documented, taught in school, buy it
at the book store.
4) Nvidia/ATI both have very efficient, existing implementations
5) DRI GL can function as a device driver - this gets X out of the
business of mucking with the PCI bus from userspace which is the
source of a lot of problems on Linux.

So it is not really GL bigotry. From my analysis of the situation GL
was the only feasible solution for Linux to pick - all of the other
choices were much harder or didn't solve all of the problems. The real
reason for picking GL was the exisitence of the large body of
completed development effort in the DRI drivers.

-- 
Jon Smirl
jonsmirl at gmail.com


More information about the dri-egl mailing list