[Xorg] X on OpenGL

[Keith Packard]

Around 13 o'clock on Jul 11, Soeren Sandmann wrote:

> I am not convinced that OpenGL has everything that applications will
> need. Some things I don't see how to support:

It's important to think of OpenGL as just the rendering back-end, not the 
whole X server architecture.  In particular, OpenGL requires external
device configuration mechanisms which are system-dependent (GLX, AGL, WGL).

And, OpenGL doesn't provide much in the way of input device support, so 
we'll want to add our own for that.

> - mode setting
>
> Changing the mode of hardware

We're already talking about moving this to an external library which can 
be shared by all graphics applications; my assumption here is that the 
system-dependent pieces for a 'Gl-solo' based X server would include an 
interface to this library.

I don't have a solid idea about how that library should be constructed; 
whether the X server should be in charge of mode selection at any level or 
whether it should just react to externally controlled events.

> - reading pixels out of the framebuffer
> 
> GetImage needs to be supported, and I'd hope that we could do better
> than just synchronize with the hardware, then read the pixels. Some
> cards can DMA pixels to main memory.

The GL API isn't required to be lame.  I believe the closed-source nVidia
driver uses DMA in this case, but the bandwidth of that operation is only a
small factor faster than the bandwidth of reading data with the CPU as it
has to transit AGP space, which (I believe) involves manual CPU cache
poisoning or uncached accesses.

> - breadcrumb
> 
> To do good-looking animations, applications will want to know when a
> given request is actually completed by the graphics hardware. So the
> API should support that.

Yeah, this would be nice; we could manage schedulin the hardware better 
with this as well.

> - gamma correct compositing
> 
> Really good-looking antialiasing will require gamma correct
> compositing. Can OpenGL do this?

Some OpenGL hardware does support this, but most does not at the current 
time.  Certainly new programmable hardware should be able to manage this, 
and I think the GL api exposes enough capability to suppor it.

> So I would like to propose that there is an abstraction layer on top
> of OpenGL that has support for these things and also knows about the X
> server select() loop.

The open source GL drivers are mutable, so we can experiment with them and 
push changes into closed source drivers as well.  The key is to figure out 
how to make this all work; the fact that we're drawing to the screen 
through the OpenGL API doesn't really change much here.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040711/20b12072/attachment.pgp>