[Public WebGL] WebGL2 element array buffer and copy buffer (5.1 Buffer Object Binding)

Kevin Rogovin ([email protected]) [email protected]
Thu Jul 9 11:23:31 PDT 2020


I can do what I plan to do without needing to generate an index
buffer, but it is not optimal. Basically, if I cannot generate an
index buffer, then I call glDrawElements(GL_TRIANGLES, ..) under
transform feedback and do glDrawArrays(GL_TRIANGLES, ) with the
transform feedback output. If I can get transform feedback to generate
an index buffer, then I can do glDrawElements(GL_POINTS,..) under
transform feedback and call glDrawElements(GL_TRIANGLES, ) to render
the content. The upshot being that then the post-vertex cache is only
in use when I can get the transform feedback to generate the index
buffer.

-Kevin

On Thu, Jul 9, 2020 at 9:11 PM Ken Russell ([email protected])
<[email protected]> wrote:
>
> GPU-side creation of index buffers is the one thing that's structurally forbidden by WebGL's rules. It has to be possible for implementations to always know the contents of index buffers without doing GPU->CPU readbacks.
>
> Your use case sounds interesting. Can you share any more details? Perhaps you could generate independent triangles into a vertex buffer instead, so that DrawArrays could be used on the results?
>
> -Ken
>
>
>
> On Thu, Jul 9, 2020 at 11:01 AM Kevin Rogovin ([email protected]) <[email protected]> wrote:
>>
>>
>> Hi,
>>
>>   My use case is that I am thinking of using transform feedback to
>> generate an index buffer. When one says "The CopyBufferSubData call
>> updates the shadow copies as well, allowing the maximum index per type
>> and range within the buffer to be computed without readback.", what I
>> do not follow is how the computation of the maximum index value per
>> type is computed on GLES3.0 without reading the buffer contents back
>> to CPU.
>>
>> However, I guess the real question for me is this: can one expect that
>> the robust access is implemented by GPU (instead of implemented by a
>> WebGL implementation bt tracking) for Dx10 backends and those OpenGL
>> and GLES backends that are operating on HW with
>> GL_ARB/KHR/EXT_robust_access?
>>
>> -Kevin
>>
>> On Thu, Jul 9, 2020 at 8:50 PM Ken Russell ([email protected])
>> <[email protected]> wrote:
>> >
>> > WebGL implementations that can't rely on robust buffer access behavior shadow the contents of ELEMENT_ARRAY_BUFFERs on the CPU. The CopyBufferSubData call updates the shadow copies as well, allowing the maximum index per type and range within the buffer to be computed without readback.
>> >
>> > The restrictions in the WebGL specification are there to avoid the need to shadow the contents of all buffers.
>> >
>> > -Ken
>> >
>> >
>> >
>> > On Thu, Jul 9, 2020 at 10:02 AM Kevin Rogovin ([email protected]) <[email protected]> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >>  Reading the text, it appears that:
>> >>
>> >> glGenBuffers(1, &index_buffer);
>> >> glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, index_buffer);
>> >>
>> >> glBindBuffer(GL_COPY_READ_BUFFER, some_other_buffer);
>> >> glBindBuffer(GL_COPY_WRITE_BUFFER, index_buffer);
>> >> glCopyBufferSubData(GL_COPY_READ_BUFFER, GL_COPY_WRITE_BUFFER,
>> >> someOffset, someLength);
>> >>
>> >> is legal because index_buffer gets the type "element array", from the
>> >> first bind and binding it to GL_COPY_WRITE_BUFFER is legal because of
>> >> what the table states.
>> >>
>> >> However, the rational states the restriction is to make sure index
>> >> values are in range, but the above scenario in order to make sure that
>> >> the indices are in range would require that a browser implementation
>> >> would need to peek the buffers via CPU which would defeat the purpose
>> >> of using glCopyBufferSubData() on any index buffer.
>> >>
>> >> What is expected to happen with the above?
>> >>
>> >> Best Regards,
>> >>  -Kevin
>> >>
>> >> -----------------------------------------------------------
>> >> You are currently subscribed to [email protected]
>> >> To unsubscribe, send an email to [email protected] with
>> >> the following command in the body of your email:
>> >> unsubscribe public_webgl
>> >> -----------------------------------------------------------
>> >>
>> >
>> >
>> > --
>> > I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today.  Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine.
>> >
>>
>> -----------------------------------------------------------
>> You are currently subscribed to [email protected]
>> To unsubscribe, send an email to [email protected] with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>
>
> --
> I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today.  Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine.
>

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list