[Haskell-cafe] Memory efficiency questions for real-time graphics

[Don Stewart]

t.r.willingham:
> On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan
> <sebastian.sylvan at gmail.com> wrote:
> > On Sat, Nov 1, 2008 at 6:57 PM, T Willingham <t.r.willingham at gmail.com>
> >>
> >> 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