[Public WebGL] Fwd: Shared Resources revisited

Benoit Jacob [email protected]
Sat Jun 22 12:42:17 PDT 2013

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

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.


> That got me thinking what would it take to make WebGL enforce the
> sharing rules in the OpenGL spec.
> The spec says you must call glFinish (or use a sync object) in the
> context modifying a resource and then bind or attach that resource in
> the context you want to see the modification to be guaranteed to be
> able to see the change.
> The problem is many drivers require far less. Some work with
> glFlush/glBind, Some work with just glFlush, no bind, others require
> the spec compliant glFInish/glBind. If we could figure out a way to
> enforce that you must use glFinish(or sync) and glBind in WebGL maybe
> it would be okay to expose that stuff as is rather than through an
> extension. For WebGL 1 we'd probably need a SYNC extension for sync
> objects otherwise so you have an alternative to the slow glFinish.
> Thinking about how to implement enforcing the rules. 
>   * Each context has a vector<WebGLSharedObject*> modified_objects.
>   * Each WebGLSharedObject has a per context safe_to_use flag. 
>   * Each WebGLSharedObject has a finished flag
>   * Each WebGLSharedObject has a fence_inserted flag
>   * Each WebGLSharedObject has a fence_id field
>   * Each context has a newest_fence_id_waited_for field
>   * There's a global fence_count
>   * Anytime a resource is modified
>       o if it's safe_to_use flag for this context is false
>           + generate INVALID_OPERATION 
>           + exit these steps
>       o set its safe_to_use flag is false for all contexts but the
>         context making the modification. 
>       o set its finished flag is set to false. 
>       o set its fence_inserted flag to false.
>       o add it to this context's modified_objects vector.
>   * Anytime a a glfinish happens
>       o set the finished flag to true for every object in the
>         context's modified_objects vector.
>       o clear the modified_objects vector.
>   * Anytime a FenceSync is called
>       o increment the global sync_count
>       o associate the sync_count with the sync object created by FenceSync
>       o assign the sync_count to every object's sync_id field in the
>         context's modified_objects vector
>       o set the fence_inserted flag to true of every object in the
>         context's modfied_objects vector 
>       o clear the modified_objects vector.
>   * Anytime a resource is used
>       o if the object's safe_to_use flag for this context is false
>   * Anytime a resource is bound/attached
>       o if the finished flag is true
>           + mark the object's safe_to_use flag for this context as true.
>       o if the fenced_inserted flag is true and this context's
>         newest_fence_id_waited is >= the object's fence_id field
>           + mark the object's safe_to_use flag for this context as true.
>       o If the object's safe_to_use flag for this context is still false
>   * Anytime WaitSync or ClientWaitSync is called
>       o set the context's newest_fence_id to the fence_count
>         associated with the given Fence object.
> This seems like it would work? The problems off the top of my head are
> 1) you can observe behavior in a worker since you can spin call
> BindXXX or attach until you get success as well as call GetSyncParameter
> It seems like it used to be a rule that you shouldn't be able to
> observe the behavior of a worker but it doesn't seem like people care
> about that anymore?
> 2) You can assume your timing works? 
> One of the things WEBGL_shared_resources was trying to prevent was a
> situation where you're running at 60fps (or 30fps) and that some
> resource you modified in one thread will be ready in another by the
> next frame so you assume it's okay to bind. I don't think this
> proposal has that problem though. If you called glFinish you can
> assume bind will work in the other context. If you called FenceSync in
> one context, bind in another context will not work unless you call
> WaitSync or ClientWaitSync
> I suppose this proposal is not "exactly like OpenGL" but it's spec
> compliant OpenGL. Native apps that get errors when ported to this code
> were just getting lucky on the platforms they were running on.
> Thoughts?

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

More information about the public_webgl mailing list