State of Linux graphics

Ian Romanick idr at
Wed Aug 31 20:11:12 PDT 2005

Hash: SHA1

Allen Akin wrote:
> On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> | 
> |         ...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.)

The difference is that there is a much larger number of state
combinations possible in OpenGL than in something stripped down for
"just 2D".  That can make it more difficult to know where to spend the
time tuning.  I've spent a fair amount of time looking at Mesa's texture
blending code, so I know this to be true.

The real route forward is to dig deeper into run-time code generation.
There are a large number of possible combinations, but they all look
pretty similar.  This is ideal for run-time code gen.  The problem is
that writing correct, tuned assembly for this stuff takes a pretty
experience developer, and writing correct, tuned code generation
routines takes an even more experienced developer.  Experienced and more
experienced developers are, alas, in short supply.

BTW, Alan, when are you going to start writing code again? >:)

> 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.
Version: GnuPG v1.2.6 (GNU/Linux)


More information about the xorg mailing list