[Public WebGL] Fwd: Shared Resources revisited

Vangelis Kokkevis [email protected]
Sat Jun 22 10:33:36 PDT 2013


I wonder whether the end result is still largely unpredictable and will
depend on the order that the draw operations get completed in by the
driver.

For example, imagine a resource with safe_to_use = true, finished = true
for all contexts and the following steps are taken in sequence:

In context A:
Bind resource
Use resource

At this point the values of safe_to_use and finished haven't changed in
either context.

In Context B:
Bind resource
Modify resource

The above sequence should generate no errors in either context. However,
depending on whether the GL calls from Context A complete before those of
Context B or not, Context A may or may not see the results from the
operation in Context B.

Vangelis



On Fri, Jun 21, 2013 at 10:53 AM, Gregg Tavares <[email protected]> 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 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
>       - if it's safe_to_use flag for this context is false
>          - generate INVALID_OPERATION
>          - exit these steps
>       - set its safe_to_use flag is false for all contexts but the
>       context making the modification.
>       - set its finished flag is set to false.
>       - set its fence_inserted flag to false.
>       - add it to this context's modified_objects vector.
>    - Anytime a a glfinish happens
>       - set the finished flag to true for every object in the context's
>       modified_objects vector.
>       - clear the modified_objects vector.
>    - Anytime a FenceSync is called
>       - increment the global sync_count
>       - associate the sync_count with the sync object created by FenceSync
>       - assign the sync_count to every object's sync_id field in the
>       context's modified_objects vector
>       - set the fence_inserted flag to true of every object in the
>       context's modfied_objects vector
>       - clear the modified_objects vector.
>    - Anytime a resource is used
>       - if the object's safe_to_use flag for this context is false
>          - generate INVALID_OPERATION or INVALID_FRAMEBUFFER_OPERATION
>       - Anytime a resource is bound/attached
>       - if the finished flag is true
>          - mark the object's safe_to_use flag for this context as true.
>       - 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.
>       - If the object's safe_to_use flag for this context is still false
>          - generate INVALID_OPERATION or INVALID_FRAMEBUFFER_OPERATION
>       - Anytime WaitSync or ClientWaitSync is called
>       - 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/8f38c4d2/attachment.html>


More information about the public_webgl mailing list