[Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
eric at anholt.net
Mon Mar 5 19:08:31 PST 2012
On Sat, 3 Mar 2012 13:21:08 -0800, Alon Zakai <alonzakai at gmail.com> wrote:
> Hi everyone,
> In the project I work on (Emscripten, an open source C/C++ to
> compile OpenGL games from desktop so that they work on
> WebGL on the web. The main remaining difficulty for us is
> to emulate the full OpenGL API using the WebGL API. WebGL
> is close to OpenGL ES 2.0, so it has shaders but lacks the
> fixed-function pipeline, glBegin etc.
> So far we have some of the OpenGL ES 2.0 API implemented,
> you can see a demo of it on the web here:
> We are looking for the best way to implement the OpenGL
> API using the WebGL API, which is basically the problem of
> implementing OpenGL on top of OpenGL ES 2.0. Note that
> API, it would be enough to implement OpenGL on OpenGL
> ES 2.0 in normal C/C++ code; we can automatically compile
> There are several commercial products doing things of that
> nature, one of the approaches seems to involve implementing
> a "virtual OpenGL driver", basically a driver that implements
> the OpenGL API and internally uses OpenGL ES 2.0 to actually
> Since Mesa implements OpenGL drivers, I was wondering if
> there is some way for us to build on the Mesa code in order
> to do that? Basically, if we had an implementation of the
> full OpenGL API in C or C++, that we could in a reasonable
> way get to utilize OpenGL ES 2.0 as its "backend", that would
> be what we are looking for. Advice on the feasibility of that
> with Mesa would be very welcome!
Kind of an amazing demo. That must have been a lot of work.
We were chatting about it here, and it seems like there are a few hard
things to handle:
1) Deprecated OpenGL functionality
Desktop GL includes ridiculous things like texture borders and GL_CLAMP
and glDrawPixels and other things we all wish we could just forget
about. ES2 doesn't have those equivalents, so you'd have to emulate
them. For a bunch of it, apps don't use it so nobody would notice.
glBitmap and glDrawPixels are reasonably popular, though. You should be
able to build those with shaders, though. You can see partial
implementations for these in on top of fixed function in Mesa as
src/mesa/drivers/common/meta.c (contributions welcome, particularly in
the form of GLSL-based implementations of them!)
2) Desktop GL functionality that only exists as extensions in ES2.
As far as I know, you don't get bindings for things like 3D textures in
WebGL, even if there's an OES extension for it. This seems hard,
without extending WebGL.
3) Converting GLSL 1.10 or 1.20 shaders to GLSL 1.00.
I think these are just a matter of transforming the language -- not
particularly differences in what features are exposed (other than 3d
textures). You might want to take advantage of the GLSL-to-GLSL
compiler at https://github.com/aras-p/glsl-optimizer to do this job by
tweaking what the backend spits out.
To solve these, I don't think building a Mesa driver would help you too
much -- it seems like a big detour to mostly get to the same point of
hooking desktop glBlendFunc up to WebGL glBlendFunc and so on (git grep
ctx-\>API suggests not too many overrides are needed).
Oh, there are a bunch of cases of desktop GL having multiple names for
the same function call (like you'll find in ES once you go poking around
their extensions), which you want to map to core ES2 functionality. You
may find the alias information Mesa's XML description of the GL API
useful for that purpose. Paul Berry's been working on writing a layer
to do this job for the piglit test suite recently using the Mesa XML
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the mesa-dev