[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Shared resources between contexts
On Sun, Jan 8, 2012 at 7:23 AM, Glenn Maynard <email@example.com> wrote:
> There's an oddity in the ES spec: FBOs may or may not be shared. This
> *might* mean that WebGL should never share WebGLFramebuffer. This would
> take some research and we don't need to look too deeply into this right now;
> I'm just dropping a note here in case I forget about it.
> On Sun, Jan 8, 2012 at 9:38 AM, Florian Bösch <firstname.lastname@example.org> wrote:
>> On Sun, Jan 8, 2012 at 3:11 PM, Rehno Lindeque <email@example.com>
>>> Although I would prefer it if all contexts were simply shared by
>>> default in order to have as little friction between engines /
>>> libraries as possible, Glenn's proposal could be satisfactory for me.
>> I disagree that contexts should be shared by default. Resource sharing has
>> real performance implications and it might create data inconsistencies.
>> Separate pieces of code intended to be separate, should not have
>> to explicitly state that they want to be separate.
> I wonder. A primary reason resource sharing isn't the default in OpenGL is
> the way OpenGL resources work. Applications in OpenGL can generate their
> own resource IDs. While you're well-advised to use glGenTextures, you don't
> actually have to; you can make up your own IDs if you want. This meant that
> sharing by default is impossible, because unrelated code that happens to
> both use OpenGL would step on each others' IDs.
> That's not the case in WebGL, because resources are identified by objects,
> not integers. Performance aside, sharing all resources would be perfectly
> safe. The only way you can access a WebGL resource is by having a reference
> to it (or a query like getParameter(CURRENT_PROGRAM)); you really can't
> access them accidentally.
> It's worth noting that there's a key difference between WebGL and OpenGL
> resource sharing: shared WebGL contexts will always be in the same thread,
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. 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. All of these issues and others seem to be solvable,
but it will probably take some time to prototype solutions for them.
I'm strongly in favor of maintaining the current semantics that
independent WebGL rendering contexts do not share resources. That is a
much better basis on which to develop more complex sharing semantics.
> where OpenGL sharing can cross threads. That could simplify implementations
> quite a lot and probably eliminate any performance impact, though this is
> more likely to help Direct3D-based implementations than ones which are a
> thin layer on top of real OpenGL (where they probably don't have enough
> control to take advantage of this).
> Glenn Maynard
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: