deferred user arrays

[José Fonseca]

There's confirmation on
https://github.com/apitrace/apitrace/blob/master/docs/BUGS.markdown#known-issues
but not much rationale.

The reason is this, when an application does

   glVertexPointer(4, GL_FLOAT, 0, 0x12345678);

there's no way to know how large is the array pointed.  It could be
anywhere from 0 to 2**32 vertices.  In fact the pointer could be invalid --
OpenGL implementations are not supposed to deference the pointer until a
draw happens.

We could play tricks like intercept malloc calls, inspect the virtual
address memory regions, and what not, but these are all best guesses that
can easily go wrong.

Only when a glDraw happens do we know, for example, that's 6 vertices:

    glDrawArrays(GL_TRIANGLES, 0, 6)

  That is , 4*4*6 = 96 bytes, if I'm not mistaken.  OpenGL must copy these
96 and only these 96 bytes now.  It must assume the pointed data changed
since glVertexPointer call, anbd that it will change again after
glDrawArrays.  And this is why user arrays are so inefficient.

Apitrace too, needs to defer all logic about user arrays to the glDraw.  It
must not touch those pointers before/after.

This is admittedly all a bit quirky.  That said, newly written applications
should stay away from user arrays and use VBOs, where performance is great,
and none of this reordering business is necessary.

Jose

On Wed, Apr 3, 2019 at 9:40 PM Josh Simonot <jsimonot at live.ca> wrote:

> Could someone help me understand why the tracing of user array pointers is
> deferred?  and can you confirm that this would cause the functions in the
> trace to be ordered differently than the order my application actually
> calls them?
>
> Thanks,
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/apitrace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/apitrace/attachments/20190404/49a9e22d/attachment.html>