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

Re: [Public WebGL] Fwd: Shared Resources revisited



On 13-06-22 03:42 PM, Benoit Jacob wrote:
On 13-06-21 01:53 PM, Gregg Tavares wrote:
So I was just about ready to land a WEBGL_shared_resources patch in Chrome

But asm.js got me thinking that there will probably be a push for making shared resources work exactly the same as OpenGL so that porting will be easier.

That, however, only applies if real-world applications that one would want to port, are already using OpenGL share groups. Are they?

Here is what I am not in a rush to start implementing WEBGL_shared_resources:

I have never heard of applications actually using share groups, at least not in ways that fundamentally require them as opposed to more fine-grained sharing mechanisms. Most of the time, what applications want to share across context is only a small minority of their OpenGL objects, and specifically a minority of their *textures*. For that, there exists a variety of existing mechanisms to allow sharing textures, which is also what browsers have to rely on anyways to composite WebGL frames in a GPU-accelerated browser compositor.

The value of focusing specifically on sharing only specific textures on a per-object opt-in basis, as opposed to sharing everything (as OpenGL share groups do) is that there are subtle performance caveats associated with OpenGL object sharing. In particular, having two OpenGL contexts in the same share group simultaneously current on two different threads is known to be a severe performance issue, as it requires certain drivers to turn on inefficient locking mechanisms.

For that reason, I expect that WEBGL_shared_resources is on a head-on collision course with other WebGL features that we're likely to implement in the near future, like WebGL-on-Web-Workers.

If I have to choose one --- I care far, far more for WebGL-on-Web-Workers than I do for WEBGL_shared_resources. It also seems that the majority of WEBGL_shared_resources use cases can be addressed by other means (e.g. targeting a single WebGL context to render to multiple canvases, as has been discussed).

Even if there was a strong need for OpenGL-like sharing of objects, I expect it'd still be mostly for sharing *textures* in which case we could make a spec allowing only to share textures with semantics that map well onto efficient texture-sharing mechanisms. But again, we haven't seen a lot of evidence for even that.

Now that I think about it, such a mechanism to share individual textures between contexts should probably be modeled after EGL streams (e.g. Android's SurfaceTexture), as that concept has already the nontrivial questions around buffering and locking sorted out specifically for textures. We already have a spec proposal for something like EGL streams for WebGL: that's WEBGL_dynamic_texture.

http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/

So to summarize, I would for now focus only on WebGL-on-Web-Workers without any sharing at first, and if and when sharing becomes a priority, assuming that it's mostly about sharing textures, I'd focus on WEBGL_dynamic_texture or a further extension based on it.

Benoit