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

Re: [Public WebGL] Shared resources between contexts





On Mon, Jan 9, 2012 at 2:34 PM, Glenn Maynard <glenn@zewt.org> wrote:
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.

I'm not sure I follow here.

different hardware capabilites: canvas 2d (size limits), images(size limits, different format support), memory(a phone has less than my desktop), touch vs mouse, tiny screen vs large, tilt vs no tilt, ability to create window (popup) vs no such ability (phones).


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.

To get speed benefits you need to be able to transfer ownership efficiently and there's no easy way to do that with processes AFAIK. So, the idea of using processes for workers has pretty much been abandoned.
 


 

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 don't see any issues here. The definition of WebGL is that any call can fail at any time. Adding shared resources and WebWorkers none of that changes. The sharing semantics seem pretty well defined. I'm probably missing something but I'm not seeing a problem right now.
 

(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