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

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



Yes, my current implementation for shared resources is there is a "shareGroup" context creation parameter.  You can share resources like this

var gl1 = create3DContext(document.createElement("canvas"));
var gl2 = create3DContext(document.createElement("canvas"), {
   shareGroup: gl1.getContextAttributes().shareGroup
});

or even more succinctly 

var gl1 = create3DContext(document.createElement("canvas"));
var gl2 = create3DContext(document.createElement("canvas"), gl1.getContextAttributes());

If you want to share with a worker you'd postMessage gl1.getContextAttributes().shareGroup which is a copyable object and then use it in the worker to put the context in the same share group.




On Wed, Jul 18, 2012 at 3:08 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:


----- Original Message -----
> Looking forward to your proposal.
>
>
> Being able to render from a worker without resource sharing is yet
> another use case but it in no way invalidates the desire for sharing
> resources to be able to apply multiple cores to a problem so, at
> least on desktop, we need also need a proposal that moves forward in
> that direction.

Yep, absolutely -- just wanted to mention it, because as you say we shouldn't
compound the two issues necessarily.  We'll keep in mind the actual sharing use case though, to make sure that the worker creation API doesn't need to be changed in order to support it (I'm assuming it'll be via passing another context to share with in the context options.. that seems the most straightforward way to request it, right?).

   - Vlad

> On Wed, Jul 18, 2012 at 1:50 PM, Vladimir Vukicevic <
> vladimir@mozilla.com > wrote:
>
>
> 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?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>