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

Re: [Public WebGL] No drawRangeElements in WebGL2 ?

I thought that the reason for drawRangeElements' existence was to help
drivers to prefetch/cache the relevant vertex data. I thought it was
fairly reasonable to imagine that that would help performance on various
hardware. Is that not the case? Anyway, glad we agree that the entry
point should be kept for now.


On 13-09-27 03:53 PM, Jeff Gilbert wrote:
> 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