On Sat, 3 Mar 2012 13:21:08 -0800, Alon Zakai <alonza...@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 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 (http://lists.freedesktop.org/archives/piglit/2012-March/001950.html)
pgpBoqTCheyfj.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
