<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 13-06-22 03:42 PM, Benoit Jacob
      wrote:<br>
    </div>
    <blockquote cite="mid:51C5FE19.4070909@mozilla.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 13-06-21 01:53 PM, Gregg Tavares
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAKZ+BNq7Sb3FxZ5a5-OT=jCopdGE-FeQN0tOO23+XnEH=YM17g@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div class="gmail_quote">So I was just about ready to land a
            WEBGL_shared_resources patch in Chrome<br>
            <div dir="ltr">
              <div><a moz-do-not-send="true"
                  href="https://codereview.chromium.org/17230006/"
                  target="_blank">https://codereview.chromium.org/17230006/</a><br>
              </div>
              <div><br>
              </div>
              <div>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.</div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      That, however, only applies if real-world applications that one
      would want to port, are already using OpenGL share groups. Are
      they?<br>
      <br>
      Here is what I am not in a rush to start implementing
      WEBGL_shared_resources:<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      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).<br>
      <br>
      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.<br>
    </blockquote>
    <br>
    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.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/">http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/</a><br>
    <br>
    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.<br>
    <br>
    Benoit<br>
    <br>
  </body>
</html>