[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: State of Linux graphics
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > 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.
> |
> | ... I don't
> | see why this can't be exposed through the Render extension. ...
> What has always concerned me about this approach is that when you add
> enough functionality to Render or some new X extensions to fully exploit
> previous (much less current and in-development!) generations of GPUs,
> you've essentially duplicated OpenGL 2.0.

I don't currently see any strong application motivation to provide this
kind of functionality in a general purpose 2D API, and so it wouldn't
make a lot of sense to push this into the 2D-centric X protocols either.

When that changes, we'll want to explore how best to provide that
functionality. One possibility is to transition applications to a pure
GL drawing model, perhaps using glitz as a shim between the 2D and 3D
worlds. That isn't currently practical as our GL implementations are
missing several key features (FBOs, accelerated indirect rendering,
per-component alpha compositing), but those things are all expected to
be fixed at some point.

The real goal is to provide a good programming environment for 2D
applications, not to push some particular low-level graphics library.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-08-31 20:32    [W:0.119 / U:11.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site