[Public WebGL] Fwd: Shared Resources revisited

Benoit Jacob [email protected]
Mon Jun 24 09:41:42 PDT 2013

On 13-06-22 03:42 PM, Benoit Jacob wrote:
> On 13-06-21 01:53 PM, Gregg Tavares wrote:
>> So I was just about ready to land a WEBGL_shared_resources patch in
>> Chrome
>> https://codereview.chromium.org/17230006/
>> 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 they?
> Here is what I am not in a rush to start implementing
> WEBGL_shared_resources:
> 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 that.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20130624/ebada460/attachment.html>

More information about the public_webgl mailing list