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

Tobias Bexelius tobias.bexelius at avalanchestudios.se
Mon Nov 3 05:31:55 EST 2008


Before Direct3D 10, its too costly to read back the updated vertex data
in every frame, which force you to make this kind of operations on the
CPU.
With D3D 10 however, you should use the new Stream-Output stage which is
used to return updated vertex data directly to a vertex buffer on the
GPU. So if you can afford a new graphics card and likes Vista, that's
the way to go :)

/Tobias



-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of T Willingham
Sent: den 2 november 2008 20:11
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Memory efficiency questions for real-time
graphics

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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


More information about the Haskell-Cafe mailing list