On 8/30/05, David Reveman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/