Xgl server

[Owen Taylor]

On Fri, 2004-11-05 at 17:27 -0700, Brian Paul wrote:

> A while back I suggested designing a very simple OpenGL glue interface 
> for creating/managing rendering contexts, drawing surfaces, etc. that 
> the GL-based X server could layer upon.  It would also work for people 
> wanting to do X-less GL applications.
> 
> mesa-solo (aka mini-glx) serves that purpose now, but it's kind of a 
> hack (the emulation of the GLX and basic Xlib functions is kind of icky).

Especially inside the X server, presumably...

> It occured to me that maybe the EGL interface (part of the OpenGL ES 
> standard) could be used instead.
> 
> The EGL spec can be found here:  http://www.khronos.org/opengles/spec.html
> 
> One potential advantage to using the EGL interface is the fact that it 
> might be supported by other hardware vendors.  Suppose, 
> hypothetically, that NVIDIA were to support EGL.  Then, the GL-based X 
> server could run on it (instead of a full X server).

Well, but once you fill in the blanks of what NativeWindowType, and
NativeDisplayType, do you really have much useful portability left?

> One thing with EGL is that it's designed to interface with an existing 
> window system, like X or WGL.  See eglCreateWindowSurface() for 
> example.  But, I think a "pure" EGL implementation is possible with a 
> little work.

It's quite possible that EGL is a useful starting point; why create
another <x>MakeCurrent name if we can use eglMakeCurrent. But in the
end, it seems like to go beyond proof-of-concept, we're going to have
a much bigger X server <=> hardware interface.

 - Implementing an X server in GL without clip lists sounds pretty
   painful. But while GLX implementations have clip lists, they aren't
   API exposed, and neither are they in EGL.

 - Xvideo - presumably there will still be card-specific Xvideo modules;
   how do they coordinate hardware access with the GL implementation?
   How do we tell the Xvideo module to render to a pbuffer? 

 - PBuffers shared between processes; we need that both for 
   direct-rendering-clients rendering to redirected windows, and 
   for passing redirected windows to a compositing manager for final
   display.

Things like that. Right now, we have a pretty good idea of what the
application API looks like, with a few holes, like the 
composite <=> pbuffer connection. It sees that it just needs to
be pushed down the stack to get a more concrete idea of what the
X server <=> GL implementation is, and what extensions to the DRI
are needed.

One other question that comes to mind: presumably, accelerated indirect
rendering is still at least a minor goal. Is implementing that on top of
EGL going to be feasible, or would you need something that mapped to GLX
in a literal one-to-one sense, but didn't use the Xlib types?

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20041105/a1eeb0fb/attachment.pgp>