[lkml]   [2005]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: State of Linux graphics
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the detailed parts if they aren't
> relevant to your area of work.
> Topics include the current X server, framebuffer, Xgl, graphics
> drivers, multiuser support, using the GPU, and a new server design.
> Hopefully it will help you fill in the pieces and build an overall
> picture of the graphics landscape.
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.

As the author of Xgl and glitz I'd like to comment on a few things.

>From the article:

> 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.

We already had a new drawing API for X, the X Render extension. Xgl is
the first server to fully accelerate 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.

> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-30 19:32    [W:0.129 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site