On Tue, Oct 28, 2008 at 3:24 PM, Sebastian Sylvan
2008/10/28 T Willingham
To give a context for all of this, I am applying a non-linear transformation to an object on every frame. (Note: non-linear, so a matrix transform will not suffice.)
Any reason why you can not do this in the vertex shader? You really should avoid trying to touch the vertices with the CPU if at all possible.
The per-vertex computation is a quite complex time-dependent function
applied to the given domain on each update. Yet even if it were
simple, I would still first implement the formulas in Haskell and
leave the optimization for later, if at all. The current C++
implementation which uses userland-memory vertex arrays already
performs very well.
On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander
Even when generating one or more copies of "world" per frame the performance stays fine and allocations are minimal.
Who says? That may be your particular experience from your particular tests. In my case, any copy of the "world" on each frame would have a catastrophic effect on the framerate, for any such definition of "world".
From what ive seen, the OpenGL calls are whats going to bottle neck.
Yes, that may as well be a tautology. The problem is sporadic lag and jittering from occasional large allocations and/or garbage collection from frequent small allocations. It's a unique situation where even the best profiling cannot pinpoint what is blatantly obvious to the human eye. Though the profiler may register it as 0.01%, the actual effect is glitchy behavior which comes off as unprofessional.