State of Linux graphics

[Matthias Hopf]

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.

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

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

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

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