Xgl server

[Brian Paul]

Owen Taylor wrote:
> 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?

I think so.  If we could create an EGL extension for screen management 
then the eglCreateWindow/PixmapSurface() functions wouldn't be used at 
all.

We could also make EGL extensions for managing cursors, etc. if needed.


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

Suppose we defined a new OpenGL extension to specify a list of scissor 
boxes, maybe glScissorListEXT().  Would that fit the bill?


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

I don't know.

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

I don't think anything in EGL precludes this.


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

Good question.  I'd have to think about that.  I'm still just 
brainstorming with the EGL idea.

-Brian