On 13-06-22 03:42 PM, Benoit Jacob
On 13-06-21 01:53 PM, Gregg Tavares
So I was just about ready to land a
WEBGL_shared_resources patch in Chrome
But asm.js got me thinking that there will probably
be a push for making shared resources work exactly the
same as OpenGL so that porting will be easier.
That, however, only applies if real-world applications that one
would want to port, are already using OpenGL share groups. Are
Here is what I am not in a rush to start implementing
I have never heard of applications actually using share groups, at
least not in ways that fundamentally require them as opposed to
more fine-grained sharing mechanisms. Most of the time, what
applications want to share across context is only a small minority
of their OpenGL objects, and specifically a minority of their
*textures*. For that, there exists a variety of existing
mechanisms to allow sharing textures, which is also what browsers
have to rely on anyways to composite WebGL frames in a
GPU-accelerated browser compositor.
The value of focusing specifically on sharing only specific
textures on a per-object opt-in basis, as opposed to sharing
everything (as OpenGL share groups do) is that there are subtle
performance caveats associated with OpenGL object sharing. In
particular, having two OpenGL contexts in the same share group
simultaneously current on two different threads is known to be a
severe performance issue, as it requires certain drivers to turn
on inefficient locking mechanisms.
For that reason, I expect that WEBGL_shared_resources is on a
head-on collision course with other WebGL features that we're
likely to implement in the near future, like WebGL-on-Web-Workers.
If I have to choose one --- I care far, far more for
WebGL-on-Web-Workers than I do for WEBGL_shared_resources. It also
seems that the majority of WEBGL_shared_resources use cases can be
addressed by other means (e.g. targeting a single WebGL context to
render to multiple canvases, as has been discussed).
Even if there was a strong need for OpenGL-like sharing of
objects, I expect it'd still be mostly for sharing *textures* in
which case we could make a spec allowing only to share textures
with semantics that map well onto efficient texture-sharing
mechanisms. But again, we haven't seen a lot of evidence for even
Now that I think about it, such a mechanism to share individual
textures between contexts should probably be modeled after EGL
streams (e.g. Android's SurfaceTexture), as that concept has already
the nontrivial questions around buffering and locking sorted out
specifically for textures. We already have a spec proposal for
something like EGL streams for WebGL: that's WEBGL_dynamic_texture.
So to summarize, I would for now focus only on WebGL-on-Web-Workers
without any sharing at first, and if and when sharing becomes a
priority, assuming that it's mostly about sharing textures, I'd
focus on WEBGL_dynamic_texture or a further extension based on it.