On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan
On Sat, Nov 1, 2008 at 6:57 PM, T Willingham
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.
I'd be very surprised to see a vertex transform that would be faster to implement on the CPU than the GPU.
It appears you misunderstood "complex time-dependent function". This is quite a bit of Haskell code involving a significant amount of octonion algebra. It could, in principle, be put on the GPU, however that should be the very last step after everything else works.
There are various ways of writing out your vertex data too, so if it doesn't change too often you can still do the transformation on the GPU,
As I previously stated, it changes every frame. Take a highly complicated function and apply it to N vertices. Now increase N until the framerate is affected. That is where I am. It is obvious that any N-sized allocations will cause the framerate to stutter. This is not just theoretical: I *see* it as I increase N while it's running. This is the point of my initial email, the subject of which is memory efficiency.