[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Issues with sharing resources across contexts



One of the things we're looking at is focusing on WebGL on workers, but without resource sharing.  We're sketching out a fairly simple API that would allow a worker thread to do full WebGL rendering to a canvas on a page, asynchronously from the main thread JS/event handling/etc.  This has a number of advantages, including being able to ensure that WebGL can deliver a smooth frame rate no matter what's going on on the main thread, being able to direct vsync (by having an explicit swapbuffers call block execution in the worker until vsync occurs), and not having to solve any of the more complex issues of webgl resource sharing across contexts and threads.  Additionally, we've found that as soon as we set up context sharing amongst contexts on multiple threads, performance drops significantly on mobile devices due to needed locking overhead.

I think someone here should hopefully have a proposal to show in the next few weeks!

    - Vlad

----- Original Message -----
> So ........... I've been playing around with sharing resources across
> WebGL contexts and I'm running into issues and looking for
> solutions.
> 
> 
> The biggest issue is that GL is command buffer driven and so calling
> some GL function doesn't mean it's actually been executed. You have
> to call glFlush. This raises lots of issues of where a program might
> work on some browser / driver / platform combo but not others if the
> users forgets to call flush.
> 
> 
> For example, assume I have 2 contexts sharing resources. gl1, and gl2
> 
> 
> 
> 
> var vs = gl1.createShader(gl1.VERTEX_SHADER);
> var fs = gl1.createShader(gl1.FRAGMENT_SHADER);
> //...
> // assume shaders are validly compiled
> // ...
> var p = gl1.createProgram();
> gl1.attachShader(p, vs);
> gl1.attachShader(p, fs);
> gl2.linkProgram(p);
> 
> 
> I attached on gl1 but linked on gl2. There's is no guarantee in GL
> that that link will succeed because the 2 attach commands may have
> only been queued and not excuted in which case the linkProgram call
> will fail with "missing shaders". The correct code is
> 
> 
> 
> var p = gl1.createProgram();
> gl1.attachShader(p, vs);
> gl1.attachShader(p, fs);
> gl1.flush(); // <--- important
> gl2.linkProgram(p);
> 
> 
> That seems unacceptable.
> 
> 
> 2 Approaches off the of my head
> 
> 
> 1) Try to make it just work without the flush
> 
> 
> One solution might be for the implementation to track which context
> last had a call. Any call to a different context causes an automatic
> implicit flush
> 
> 
> 2) Try to make it fail when not done correctly
> 
> 
> This solution would be to try to track of an object is "dirty" (state
> has been changed) and no flush has been issued since then for that
> object. When an object is used, if it's dirty then either a flush is
> issued (which is solution #1) or a error is generated. ("called
> function on dirty object, did you forget to call flush?")
> 
> 
> Neither solution seems ideal. Worse, whatever solution is chosen also
> has issues if we ever get WebGL in Workers.
> 
> 
> A 3rd solution is just to leave it with the flush required and
> forgetting means you get random success / failure. No such a great
> prospect. :-(
> 
> 
> Thoughts?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------