Indirect rendering with OpenGL-ES in X?
david at protonic.nl
Tue Oct 6 23:45:28 PDT 2009
First of all, thanks a lot for your reply, it is more or less the kind
of answer I had hoped for.
Adam Jackson wrote:
>> 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.
I would love to do that, but here in the embedded world, I fear we have
little other choice. And believe me, I have caused quite some noise
about this with the chip's manufacturer....
> 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.
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.
More information about the xorg-devel