t.r.willingham: > On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan > <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 1, 2008 at 6:57 PM, T Willingham <[EMAIL PROTECTED]> > >> > >> 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.
I'm glad things are going well. Do you have the code somewhere for review? -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe