State of Linux graphics

[Jon Smirl]

On 8/31/05, Matthias Hopf <mhopf at suse.de> wrote:
> On Aug 30, 05 14:13:35 -0400, Jon Smirl wrote:
> > On 8/30/05, David Reveman <davidr at novell.com> wrote:
> > > 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
> 
> What do you refer to with Xgl? For me it is the superset of Xegl, Xglx,
> and all other possible Xservers that are using OpenGL as an abstraction
> layer.
> So yes, of course, Xgl can run standalone. If it cannot, so cannot Xegl.

Xgl is the crossplatform code it's can't run anywhere. You need to
combine Xgl with platform specific drivers.

Xglx = Xgl running nested on GLX
Xegl = Xgl running standalone on OpenGL/EGL
Xwgl = Xgl running on the MS wgl OpenGL extensions
Wagl = Xgl running on the Apple agl OpenGL extensions


> > 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
> 
> Unless the according extensions are not implemented in more (and even
> propriotory) drivers, that won't be a possibility. I always said that I
> see major migrations to Xgl no sooner than in two years from now.
> 
> > 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
> 
> They are mainstream already. There is just a ton of legacy hardware
> sitting around that doesn't do programmable stuff, and that won't change
> in two years. We're still dealing with chips like the Mach64, so we
> won't be able to nuke non-programmable stuff for some decades.

There is no proposal to make GPU programmability a requirement; only a
proposal to make it accessible. I would prefer to see programmability
exposed via an existing, standardized API instead of designing a new
one.

> > 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.
> 
> I wouldn't do that. OpenGL is not really a suitable API for rendering
> 2D.  It's too low level, and overhead is too high (you have to change
> tons of render states all the time).  Render is much better for that.
> 
> Maybe we should look into a scene graph API for mixed 2D/3D GUIs.
> Avalon is doing it, maybe it's a wise decision.  Whether XML is remains
> to be seen.  But I don't remember whether XML is transmitted to the
> graphics engine, or whether it is only used for storing/designing the
> GUI elements.

Scene graph API is another topic that was not addressed in the paper.
I do agree that it is worthwhile to expore building one.

> 
> > > 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.
> 
> I doubt. AFAIK EXA does *not* accelerate XRender. It provides the
> framework for efficient use of XRender, but everything is rendered in
> software.
> That's the key point of EXA, the driver is simple, stupid, thus it can
> be made fast, and it is pretty easy to implement.
> 
> > > 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.
> 
> I'm not exactly sure at the moment what we would need this interface
> for. I'm trying to collect a few possibilities, but I'm not sure which
> of them make any sense. I think many of these issues are better dealt
> with on a different level (so that not every application has to
> provide shaders for each issue).
> 
> - Color conversion (may be stuff like calibration as well)
> - Higher-order image scaling (bicubic, lanzcos)
> - Image filtering
> - Nontrivial (i.e. nonlinear) transformations
> - Unusual composition algorithms (non-photorealistic transparency)
> - Everything related to shading (that would imply 3D objects, though)

I referenced this paper
http://www.loria.fr/~levy/publications/papers/2005/VTM/vtm.pdf

They implement scalable font generation on the GPU using shaders. The
fonts work equally well for 2D and 3D. This is definitely only
something that can be done on high end hardware today, but we need to
allow room in our APIs for something like this in the future. Our
current subpixel, antialiased fonts are superior today but I have to
wonder if that will be true on GPUs built two years from now.

> 
> CU all
> 
> Matthias
> 
> --
> Matthias Hopf <mhopf at suse.de>       __        __   __
> Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
> Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
Jon Smirl
jonsmirl at gmail.com