----- 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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
