[Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?

[Benoit Jacob]

----- Original Message -----
> 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
> > JavaScript compiler that utilizes LLVM), we want to be able 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:
> > 
> > http://people.mozilla.org/~eakhgari/es2gears.html
> > 
> > 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
> > there is no problem with the fact that WebGL is a JavaScript
> > API, it would be enough to implement OpenGL on OpenGL
> > ES 2.0 in normal C/C++ code; we can automatically compile
> > that code into JavaScript.
> > 
> > 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
> > render.
> > 
> > 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

This part 1) is where we need to focus, as the other parts seem less concerning for porting real-world games (I elaborate below).

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

That's exactly where we were hoping that Mesa might be able to help: doesn't Mesa already have an implementation of these OpenGL 1 pieces on top of something closer to OpenGL ES 2 (which IIUC is far closer to how modern hardware really works)?

If Mesa had an implementation of GL1 on top of GLES2, Emscripten (Alon's C/C++-to-JS translator) could compile it to JS.

> 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!)

Thanks for the pointer but that (a GLES2-based implementation) is precisely what we're looking for :-)

Before we'd start caring about glBitmap and glDrawPixels, we have more fundamental things to implement:
 - glBegin ... glVertex ... glEnd
 - glShadeModel(GL_FLAT)   (this one seems really hard to do with OpenGL ES2, a real capability regression from OpenGL [ES] 1 it seems!)
 - display lists
 - the lighting model (glLight, glMaterial)

Does Mesa have code that could be reused to implement some of that on top of ES2?

> 
> 2) Desktop GL functionality that only exists as extensions in ES2.

I wouldn't worry about that for now. For the time being, we'd be very happy if we could compile, say, Quake 3 to WebGL. In other words, there's a lot that can be done before we'd have to worry about functionality that requires more ES2 extensions.

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

3D textures haven't been made a WebGL extension because they seem relatively little used, the applications that really need them in WebGL (medical visualization) have successfully been emulating them with large 2D textures and a smart fragment shader, and the benefit of exposing real 3D textures seems not sufficient to justify the portability regression they would introduce (since content requiring 3D textures would not run on hardware that doesn't support them).

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

We already have a GLSL-to-GLSL compiler provided by ANGLE, so we can perform source transformations as needed, but again, I wouldn't worry about this at this point --- again, we'd be happy to run Quake3 at this point.

Cheers,
Benoit

> 
> 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
> (http://lists.freedesktop.org/archives/piglit/2012-March/001950.html)
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>