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

Benoit Jacob bjacob at mozilla.com
Tue Mar 6 05:24:20 PST 2012


----- Original Message -----
> 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).

Eric, I reread this part of your email and only understand it now that I've read Michel's email.

I understand that

    OpenGL call -> Gallium3D -> WebGL call

seems like useless complication and when possible, it is much better to map OpenGL calls directly to WebGL calls without going through Gallium3D.

Emscripten already maps OpenGL ES 2 calls directly to WebGL calls. So in principle, we would only need to go through Gallium3D for the OpenGL calls that are not part of OpenGL ES 2. In practice, there is a problem: if some/many calls skip Gallium3D, then Gallium3D won't know about all the state.

Maybe if going through Gallium3D is cheap enough, we should not worry and just enable a "OpenGL mode" where all the calls go through Gallium3D, while in "OpenGL ES2 mode" we'd keep our direct mapping to WebGL calls. Do you expect that going through Gallium3D will incur a large overhead for OpenGL ES 2 calls? What makes me hopeful is that in WebGL, call overhead is already much larger than in OpenGL, so hopefully the Gallium3D overhead would be negligible.

But if you think that Gallium3D overhead is going to be large (when all this is compiled to JavaScript) then my next question would be, do you see a way that we could pay this overhead only for OpenGL 1 calls without affecting the performance of OpenGL ES 2 calls?

Cheers,
Benoit


More information about the mesa-dev mailing list