State-of-the-Art OpenGL

[Joakim Sindholt]

On Thu, 2010-12-09 at 21:11 +0100, Carl-Philip Haensch wrote:
> > There's a couple of tricky things about GL in Wayland right now. First
> > of, it's all EGL and GLES2.  Longer term we'll need an answer for apps
> > that need full GL, but the problem is that libGL pulls in GLX and all
> > the X dependencies.  The other thing is that there is no EGLSurface
> > support in Wayland, you just render to a FBO and push the color buffer
> > to the Wayland compositor.  We may add an EGLSurface for Wayland at
> > some pointer, but for now there's a little more bookkeeping to do on
> > the client side.
> 
> That means in near future there will be no GL Support?
> afaik, libGL is based on X-forwarding, so there would be a need of  
> reimplementing all GL stuff of the X11 for a back-buffer-drawing  
> library?

EGL is an API for creating a context, regardless of Khronos API. Wayland
uses OpenGL ES 2.0 because it's the most widely used one on mobile
platforms and trivial to implement with any GPU produced in the last
10ish years. There will still be full GL support and libGL+drivers
(Mesa3D) works with both the X11 GLX stack using remote calls and using
the DRI/DRI2 interfaces which amount to the same as you would do in
Wayland.

> I would like to know how the shared buffer exactly works. It sounds  
> very interesting to compose shared FBOs, but how is it exactly done?
> 
> Greets

Shared buffer is basically done by the kernel assigning each buffer a
name (32bit integer) that different driver instances can then use. So
you can allocate a DRM buffer, pass it to your OpenGL 3.0 capable
driver, and then give it to Wayland to composite with OpenGL ES 2.0. As
long as the two agree on the format of said buffer, all DRM-based
implementations of different APIs can work with the same buffers.
For example, I could port my D3D9 state tracker project to Wayland and
it would work just as well as any Khronos API currently does.