Re: State of Linux graphics

[Jim Gettys <jg@freedesktop.org>]

Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope).  If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
				- Jim


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.  You need to identify the
> resources to be managed (framebuffer objects, vertex objects, textures,
> programs of several kinds, etc.); explain how they're specified and how
> they interact and how they're owned/shared; define a vocabulary of
> commands that operate upon them; think about how those commands are
> translated and executed on various pieces of hardware; examine the
> impact of things like graphics context switching on the system
> architecture; and deal with a dozen other matters that have already been
> addressed fully or partly in the OpenGL world.
> 
> I think it makes a lot of sense to leverage the work that's already been
> done:  Take OpenGL as a given, and add extensions for what's missing.
> Don't create a parallel API that in the long run must develop into
> something at least as rich as OpenGL was to start with.  That costs time
> and effort, and likely won't be supported by the hardware vendors to the
> same extent that OpenGL is (thanks to the commercial forces already at
> work).  Let OpenGL do 80% of the job, then work to provide the last 20%,
> rather than trying to do 100% from scratch.
> 
> Allen
> _______________________________________________
> xorg mailing list
> xorg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

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