[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] No drawRangeElements in WebGL2 ?
On 13-09-27 07:09 PM, Kenneth Russell wrote:
> For the record, I don't think there is any point in exposing this
> method right now. It can not provide any significant performance
> advantage given WebGL's current constraints. Specifically: because
> drawElements requires an INVALID_OPERATION error to be generated if
> any of the indices are out of range, slow CPU-side validation is
> required whenever new indices are uploaded. This is the major
> performance cliff that WebGL applications fall off, and the one that
> should receive the most attention.
Please correct me if I'm wrong. The code I linked to in the first email
in this thread should handle this efficiently, no? It works by caching
element arrays in a binary heap. The validation work in a drawElements
call on N vertices is O(log N), and the cache-updating work in a
bufferSubData call on N vertices is O(N). As such, I don't see a
performance cliff there (though I could be missing something), and I
don't see yet why WebGL couldn't benefit from drawRangeElements as much
as OpenGL does.
> There's been discussion in the working group about using
> GL_ARB_robustness and GL_ARB_robust_buffer_access_behavior to
> respecify how WebGL's drawElements deals with out-of-range indices.
> Only once that's done do I think there's any point in exposing
Before I start considering relying on driver features for security, I
would have to be convinced that the alternative is really too slow. But
if what I said above is correct, then even without relying on such a
driver feature and implementing these checks purely in the browser, we
do not spend much time in this validation code.
Maybe a testcase causing Firefox to spend much time in this code would
be the best way to force me to reconsider.
> On Fri, Sep 27, 2013 at 1:26 PM, Jeff Gilbert <email@example.com> wrote:
>> This is indeed the case. The spec for this even includes queries for what a good size is.
>> We might be tracking a global min and max for a buffer, but the user might ask for a smaller [min,max] range for drawRangeElements, such that length([min,max]) is <= MAX_ELEMENTS_VERTICES. We might then have to do a little bit of extra work to authenticate this smaller range (once) and then we'd be able to pass it down to the driver.
>> ----- Original Message -----
>> From: "Benoit Jacob" <firstname.lastname@example.org>
>> To: "Jeff Gilbert" <email@example.com>
>> Cc: "public webgl" <firstname.lastname@example.org>, "Brandon Jones" <email@example.com>, "Kenneth Russell" <firstname.lastname@example.org>
>> Sent: Friday, September 27, 2013 1:17:27 PM
>> Subject: 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.
>>> ----- Original Message -----
>>> From: "Benoit Jacob" <email@example.com>
>>> To: "public webgl" <firstname.lastname@example.org>
>>> Cc: "Brandon Jones" <email@example.com>, "Kenneth Russell" <firstname.lastname@example.org>
>>> Sent: Friday, September 27, 2013 5:13:39 AM
>>> Subject: [Public WebGL] No drawRangeElements in WebGL2 ?
>>> I just read this on
>>> http://blog.tojicode.com/2013/09/whats-coming-in-webgl-20.html :
>>> //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
>>> Unit test:
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: