Re: State of Linux graphics

[Jon Smirl]

On 8/30/05, David Reveman <davidr@xxxxxxxxxx> wrote:
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as a device
> > driver. Xgl maintained all of the existing X APIs as primary APIs.
> > No new X APIs were offered and none were deprecated.
> ..
> > But Xgl was a near term, transition design, by delaying demand for
> > Xgl the EXA bandaid removes much of the need for it.
> 
> I've always designed Xgl to be a long term solution. I'd like if
> whatever you or anyone else see as not long term with the design of Xgl
> could be clarified.

Xgl doesn't run standalone, it needs either Xegl or Xglx. Xglx isn't
really interesting since you're running an X server inside of another
one. It's a good environment for software developers but I don't think
you would want to base a desktop distribution on it.

The leaves Xegl. If Xegl were to enter widespread use by the end of
2006 it would be the right solution. But I don't think it is going to
make it anywhere close to the end of 2006 since X11R7 and EXA are
going to be released in front of it. I suspect those two releases will
just be getting widespread by the end of 2006.

So we are looking at 2007. That means two more year's advances in
hardware and things like a NV 6800GT will be $40. In that timeframe
programmable hardware will be mainstream. We also have time to fix
some of the problem in the current server. As described at the end of
the paper a new server design would feature OpenGL as it's primary
API, xlib would still be supported but at a secondary status.

> We already had a new drawing API for X, the X Render extension. Xgl is
> the first server to fully accelerate X Render.

I think the EXA people will say they have the first server in
distribution that fully accelerates X Render.

> 
> > Linux is now guaranteed to be the last major desktop to implement a
> > desktop GUI that takes full advantage of the GPU.
> 
> I'm not certain of that.

I can't see any scenario where Linux can put together a full GPU based
desktop before MS/Apple. We aren't even going to be close, we are at
least a year behind. Even if we fix the server all of the desktop
components need time to adjust too.

> 
> > In general, the whole concept of programmable graphics hardware is
> > not addressed in APIs like xlib and Cairo. This is a very important
> > point. A major new GPU feature, programmability is simply not
> > accessible from the current X APIs. OpenGL exposes this
> > programmability via its shader language.
> 
> That's just because we haven't had the need to expose it yet. I don't
> see why this can't be exposed through the Render extension. The trickier
> part is to figure out how we should expose it through the cairo API but
> that's not an X server design problem.

It will be interesting to read other X developer's comments on
exposing programmable graphics via render.

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/