Re: State of Linux graphics

[Allen Akin <akin@pobox.com>]

On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
| On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
| > ...
| 
| Right, the goal is to have only one driver for the hardware, whether an
| X server for simple 2D only environments or a GL driver for 2D/3D
| environments. ...

I count two drivers there; I was hoping the goal was for one. :-)

|           ... I think the only questions here are about the road from
| where we are to that final goal.

Well there are other questions, including whether it's correct to
partition the world into "2D only" and "2D/3D" environments.  There are
many disadvantages and few advantages (that I can see) for doing so.

[I'm going to reorder your comments just a bit to clarify my replies; I
hope that's OK]

|                                            ... However, at the
| application level, GL is not a very friendly 2D application-level API.

The point of OpenGL is to expose what the vast majority of current
display hardware does well, and not a lot more.  So if a class of apps
isn't "happy" with the functionality that OpenGL provides, it won't be
happy with the functionality that any other low-level API provides.  The
problem lies with the hardware.

Conversely, if the apps aren't taking advantage of the functionality
OpenGL provides, they're not exploiting the opportunities the hardware
offers.  Of course I'm not saying all apps *must* use all of OpenGL;
simply that their developers should be aware of exactly what they're
leaving on the table.  It can make the difference between an app that's
run-of-the-mill and one that's outstanding.

"Friendliness" is another matter, and it makes a ton of sense to package
common functionality in an easier-to-use higher-level library that a lot
of apps can share.  In this discussion my concern isn't with Cairo, but
with the number and type of back-end APIs we (driver developers and
library developers and application developers) have to support.

|                                                         ... GL provides
| far more functionality than we need for 2D applications being designed
| and implemented today...

When I look at OpenGL, I see ways to:

	Create geometric primitives
	Specify how those primitives are transformed
	Apply lighting to objects made of those primitives
	Convert geometric primitives to images
	Create images
	Specify how those images are transformed
	Determine which portions of images should be visible
	Combine images
	Manage the physical resources for implementing this stuff

With the exception of lighting, it seems to me that pretty much all of
that applies to today's "2D" apps.  It's just a myth that there's "far
more" functionality in OpenGL than 2D apps can use.  (Especially for
OpenGL ES, which eliminates legacy cruft from full OpenGL.)

|                    ... picking the right subset and sticking to that is
| our current challenge.

That would be fine with me.  I'm more worried about what Render (plus
EXA?) represents -- a second development path with the actual costs and
opportunity costs I've mentioned before, and if apps become wedded to it
(rather than to a higher level like Cairo), a loss of opportunity to
exploit new features and better performance at the application level.

|                  ...The integration of 2D and 3D acceleration into a
| single GL-based system will take longer, largely as we wait for the GL
| drivers to catch up to the requirements of the Xgl implementation that
| we already have.

Like Jon, I'm concerned that the focus on Render and EXA will
simultaneously take resources away from and reduce the motivation for
those drivers.

| I'm not sure we have any significant new extensions to create here;
| we've got a pretty good handle on how X maps to GL and it seems to work
| well enough with suitable existing extensions.

I'm glad to hear it, though a bit surprised.

| This will be an interesting area of research; right now, 2D applications
| are fairly sketchy about the structure of their UIs, so attempting to
| wrap them into more structured models will take some effort.

Game developers have done a surprising amount of work in this area, and
I know of one company deploying this sort of UI on graphics-accelerated
cell phones.  So some practical experience exists, and we should find a
way to tap into it.

| Certainly ensuring that cairo on glitz can be used to paint into an
| arbitrary GL context will go some ways in this direction.

Yep, that's essential.

|         ...So far, 3D driver work has proceeded almost entirely on the
| newest documented hardware that people could get. Going back and
| spending months optimizing software 3D rendering code so that it works
| as fast as software 2D code seems like a thankless task.

Jon's right about this:  If you can accelerate a given simple function
(blending, say) for a 2D driver, you can accelerate that same function
in a Mesa driver for a comparable amount of effort, and deliver a
similar benefit to apps.  (More apps, in fact, since it helps
OpenGL-based apps as well as Cairo-based apps.)

So long as people are encouraged by word and deed to spend their time on
"2D" drivers, Mesa drivers will be further starved for resources and the
belief that OpenGL has nothing to offer "2D" apps will become
self-fulfilling.

| So, I believe applications will target the Render API for the
| foreseeable future. ...

See above. :-)

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