deferred user arrays

[José Fonseca]

We could stop the reordering when recording, but not when replaying,
therefore we'd need to bend backwards and do complicated state tracking
there.  We'd need a post-processing step, or queue lots of calls in
memory.  Perhaps less confusing for users, but from my (maintainer) POV,
just as bad, if not worse.

> But maybe its not worth it if everyone should swear off user arrays
anyway

Yep. That's my current take.  Perhaps there's something that could be done
when we finally tackly persistently mapped buffers,
https://github.com/apitrace/apitrace/issues/232 , but  until then I'm not
going out of my way to improve user arrays.   TBH, my main grievance with
the current state of affairs, is not the reordering, but the fact that the
same data is serialized over and over and over again, on every draw.  Which
yields huge and cumbersome traces.  That's what I'd like to avoid the most.

Jose

On Thu, Apr 4, 2019 at 2:14 PM Josh Simonot <jsimonot at live.ca> wrote:

> That makes a lot of sense!
> Couldn't you stop the reordering of events by tracing the pointer calls as
> they happen, and only defer the data copy? Send the data with some sort of
> 'fake' trace event that doesn't appear in the trace?
>
> But maybe its not worth it if everyone should swear off user arrays anyway
> 😋
>
> Thanks,
> Josh
>
> ------------------------------
> *From:* José Fonseca <jose.r.fonseca at gmail.com>
> *Sent:* April 4, 2019 9:27 AM
> *To:* Josh Simonot
> *Cc:* apitrace at lists.freedesktop.org
> *Subject:* Re: deferred user arrays
>
> 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/20190405/a096a040/attachment.html>