Indirect rendering with OpenGL-ES in X?

[Adam Jackson]

On Wed, 2009-10-07 at 08:45 +0200, David Jander wrote:

> >> 3. Since the applications will run locally anyway, implement some hack 
> >> in the X-server, like shadow-buffers, to update screen contents 
> >> efficiently from EGL-pbuffer surfaces.
> > 
> > You'd want to backend the X server's GLX provider onto your GLES stack,
> > which is more or less straightforward, and then just run all GLX apps
> > indirect.  GLX pixmap support would be fairly easy, just don't advertise
> > any GLX visuals and only-pixmap-enabled fbconfigs, and either point the
> > pixmap's storage to the GLES stack's storage (if it lets you get a
> > pointer to it) or copy the bits back and forth (if it doesn't).  GLX
> > window support would be similarly easy, just allocate the back buffer as
> > an EGL pbuffer and copy out of it on SwapBuffers, and hope no one's
> > stupid enough to try GL_FRONT rendering.
> 
> Sounds interesting. If I understand correctly, I would be using the GLX 
> protocol unmodified for GLES (is that possible?), and just write a layer 
> to hook the backend up to the GLES libraries. Not advertising any GLX 
> visuals would be a way of saying: "I don't support rendering to the 
> screen directly". The only caveat will be that probably no _real_ GLX 
> application will work since the backend is GLES and not plain OpenGL. 
> Since we will be developing our own apps, this shouldn't be a problem.

It's possible to emulate most (possibly all) of GL on top of GLES.  See
for example http://sf.net/projects/dogless .  What I was proposing is
basically that same kind of thunking exercise, but done inside the X
server and implementing the server's GLX provider.

So then the question of whether "real" GLX apps work is a bit fuzzier;
it depends what they need.  If they need a double-buffered GLX visual,
you'd have to actually implement windowed rendering, using the EGL
pbuffer as the back buffer.  If they need the selection API, you might
be out of luck.  (Pretty sure selection is gone from GLES, anyway.)

But yeah, if you're doing your own apps and don't care about really
being conformant GLX, then just don't hit the bits of GLX you don't
implement.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091007/f0522703/attachment.pgp