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

Re: [Public WebGL] Shared resources between contexts

On Fri, Jan 6, 2012 at 3:27 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
Doh, I missed your post Glenn, That looks the same.

The only real difference is the extension mechanism.

> gl2 = canvas2.getContext("webgl", { sharedResourceGroup: gl1.sharingGroup });

There probably shouldn't be an attribute to get to other contexts in the share list.  That would cause GC behavior to be exposed to scripts, which is something the platform carefully avoids.

On Mon, Jan 9, 2012 at 1:44 PM, Kenneth Russell <kbr@google.com> wrote:
This isn't a good assumption to make. There are many reasons why it
would be useful to be able to access WebGL from a worker thread.

(I assume you mean "to access WebGL resources"; I certainly agree that WebGL should be usable from threads.)
One is to be able to upload textures or compile shaders in the background,
to avoid any framerate hitches on the main thread. Another is to be
able to do offscreen rendering in the worker thread and post the
results to the main thread for display within a canvas.

Several issues would need to be solved in order to achieve this sort
of sharing. First, WebGLRenderingContext is currently implicitly tied
to a Canvas. Second, there is no way to identify a
WebGLRenderingContext in another thread since they can't be sent via
postMessage. Third, semantics would need to be defined for when
rendering results from one thread are guaranteed to be available on
another thread.

(That's ES C.2, right?)

Web APIs normally follow strict rules for threading:

- Running code is, from the perspective of the programmer, synchronous.  Something happening in one thread can't have visible effects in another thread.
- Code is deterministic; code behaves the same way every time (given the same initial state) in all browsers.

Of course, there are exceptions; those that aren't legacy mistakes are made with care.

I mention this not to say this shouldn't be done, but just as a caution: if you expose cross-thread shared WebGL resources, you're going to be deviating substantially from the design of the platform.  WebGL already does that in significant ways (nondeterministic context loss; different hardware capabilities, like MAX_TEXTURE_SIZE), and this would push it yet further away.  The more you do that, the less the API will fit in with the rest of the platform.

Another thing to note is that workers are designed so that they can be implemented either with a threading model or a process model; the inter-thread boundary is defined in a way that allows either.  Shared WebGL resources would probably only work with the threading model, not the process model.  I don't know if any Web Workers implementations actually use the process model, but it's something to keep in mind.  At minimum, it suggests that shared resources should always be an optional feature, not promoted to a core feature, to avoid creating a design conflict.

All of these issues and others seem to be solvable,
but it will probably take some time to prototype solutions for them.

A prerequisite would be having WebGL available to workers in the first place.  There are big hurdles to that (which I'm sure you're well aware of--the DOM thread-safety issue).  I do hope this happens eventually.

(I wouldn't mind seeing shared resource support across threads in WebGL and I don't object to designing with it in mind, even though I'm a bit skeptical of it ever actually happening.)

Glenn Maynard