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

Re: [Public WebGL] No drawRangeElements in WebGL2 ?



The argument at the F2F was that drawRangeElements won't be any different than calling drawElements, since we already have to guarantee that the element indexes lie with in a certain range. That is, we could already treat any call to drawRangeElements as a call to drawElements.

However, I believe that the extension spec points out a couple areas where a user may be better able to fit a smaller range into drawRangeElements, and receive performance benefits. As such, we should keep this entry point, since there is the distinct possibility it could improve performance, especially on some hardware. At worst, it ends up not being useful, and we deprecate it.

-Jeff

----- Original Message -----
From: "Benoit Jacob" <bjacob@mozilla.com>
To: "public webgl" <public_webgl@khronos.org>
Cc: "Brandon Jones" <bajones@google.com>, "Kenneth Russell" <kbr@google.com>
Sent: Friday, September 27, 2013 5:13:39 AM
Subject: [Public WebGL] No drawRangeElements in WebGL2 ?

Hi,

I just read this on
http://blog.tojicode.com/2013/09/whats-coming-in-webgl-20.html :

    /*drawRangeElements*//
    //Similar to mapped buffers, there doesn't appear to be a good way
    to expose this function and deliver the performance benefits that
    are assumed to come with it's use. (The WebGL implementation would
    have to re-validate all it's indices to ensure that they all fall
    within the range specified.) As such drawRangeElements it probably
    won't make it into the final spec, but we'd appreciate external
    feedback on how widely used/necessary this function is in ES 3.0 or
    desktop GL content.//

    /

And in the spec, http://www.khronos.org/registry/webgl/specs/latest/2.0/

  /* TODO(kbr): argue against exposing this because it can't safely
     offer better performance than drawElements */
  void drawRangeElements(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, GLintptr offset);

Could you explain what the concern is here?

Already for drawElements in WebGL 1.0, implementations must be able to
quickly compute the maximum in any interval within the bound element
array, and need to be able to react quickly to partial element array
buffer updates with bufferSubData. There is no additional difficulty
with extending that to also be able to compute the minimum, that's
really the same problem that we already had to solve before! Having both
the maximum and the minimum, we have what we need to validate the
drawRangeElements call, so we can just pass it on to the GL. Am I
missing something?

For example, in Mozilla's implementation, the validation for
drawElements already in WebGL 1.0 uses a binary heap (a binary tree
stored contiguously in memory) to compute the maximums. Just doing the
same for minimums should not be a problem. Memory usage isn't a problem
either, as the element array entries are grouped by 8 before
constructing the tree, so the tree is fairly small compared to the
original buffer.

The code is very self-contained and reusable (see the big comment in the
.cpp)

http://dxr.mozilla.org/mozilla-central/source/content/canvas/src/WebGLElementArrayCache.h
http://dxr.mozilla.org/mozilla-central/source/content/canvas/src/WebGLElementArrayCache.cpp

Unit test:

http://dxr.mozilla.org/mozilla-central/source/content/canvas/compiledtest/TestWebGLElementArrayCache.cpp

Benoit

-----------------------------------------------------------
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
-----------------------------------------------------------