Indirect rendering with OpenGL-ES in X?

Adam Jackson ajax at nwnk.net
Tue Oct 6 08:41:16 PDT 2009


On Tue, 2009-10-06 at 10:51 +0200, David Jander wrote:
> Hi all,
> 
> My excuses if this question may seem slightly off-topic (I hope it is 
> not). In the light of the painful state of hardware acceleration support 
> for embedded devices using X, I have been wondering about the following 
> possibilities, and want to know if someone else has thought of, or tried 
> something like this before:
> 
> I have:
> An embedded (linux-) system with a display interface (linux 
> framebuffer), running kdrive Xserver (Xfbdev) and a MBX 3-D core with 
> binary OpenGL-ES 1.1 and EGL libraries.

First, obviously, you are in a world of hurt for running a driver you
can't modify.  I gently suggest that such hardware _not_ be improved in
the open code as punishment, so that market forces drive people to
hardware with a sensible driver story.

That said...

> I want:
> To be able to develop an X-application that gets OpenGL (-ES) graphics 
> rendered into an X-window (local rendering only).
> 
> The problem:
> The OpenGL-ES/EGL libraries that are delivered with the hardware, do not 
> support any other than full-screen rendering (EGL is restricted to the 
> NULL-window) or rendering to off-screen buffers (pbuffer support).

I think you want:

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

- 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/20091006/e7c88d51/attachment.pgp 


More information about the xorg-devel mailing list