brian.paul at tungstengraphics.com
Mon Nov 8 08:52:05 PST 2004
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
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
> 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
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.
More information about the xorg