[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.
> 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.)

Not with this kind of attitude, anyway. Every hardware capability
(shared memory across threads) that WebGL turns up its nose at will be
brought to unilateral proprietary platforms anyway.

Google is simultaneously exercising ridiculous control over WebGL and
developing competing technology in Chrome with NaCl and friends. This
is not a minor conflict of interest.

Push the envelope. The day is already growing late and the coming
decades will not be kind to freedom. There is no fundamental
technological hurdle to these features -- we could have had them a
decade ago. These capabilities are difficult to get right but will
become vitally important in <3yrs with many-core chips and
heterogeneous compute.

Put them on the roadmap and stop consigning the Web to also-ran
status. Drive the technology like humanity's freedom depends on it --
our grandchildren will thank you.


> --
> Glenn Maynard

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