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

newer
Re: [Haskell-cafe] Efficient...

older
Making 'community' server our...

T Willingham

2 Nov 2008 2 Nov '08

2:10 p.m.

On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan wrote:

...

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.

Show replies by date

Don Stewart

2 Nov 2 Nov

2:13 p.m.

New subject: Memory efficiency questions for real-time graphics

t.r.willingham:

...

On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan wrote:

...
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.

I'm glad things are going well. Do you have the code somewhere for review? -- Don

T Willingham

4:23 p.m.

New subject: Memory efficiency questions for real-time graphics

On Sun, Nov 2, 2008 at 2:13 PM, Don Stewart wrote:

...

t.r.willingham:

...
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?

If you read my initial post, you'll see that I am looking to convert an existing C++ application to Haskell. Above I am describing the current C++ implementation.

Tobias Bexelius

3 Nov 3 Nov

5:31 a.m.

New subject: Memory efficiency questions for real-time graphics

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@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of T Willingham Sent: den 2 november 2008 20:11 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Memory efficiency questions for real-time graphics On Sat, Nov 1, 2008 at 2:11 PM, Sebastian Sylvan wrote:

...

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.

...

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,

Svein Ove Aas

10:45 a.m.

New subject: Memory efficiency questions for real-time graphics

On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius wrote:

...

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 :)

Or you could use OpenGL, which has supported that since the first GPUs that did were released.

Sebastian Sylvan

4 Nov 4 Nov

2:05 p.m.

New subject: Memory efficiency questions for real-time graphics

On Mon, Nov 3, 2008 at 3:45 PM, Svein Ove Aas wrote:

...

On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius wrote:

...
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 :)

Or you could use OpenGL, which has supported that since the first GPUs that did were released.

I think that came with OpenGL 3.0. Unless you're counting vendor-specific extensions... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

Tobias Bexelius

5 Nov 5 Nov

5:08 a.m.

New subject: Memory efficiency questions for real-time graphics

I believe Svein is thinking of render-to-texture which indeed could be used to emulate Stream-Out functionality (but with reduced performance of course). This is also hardware specific and was still not supported on the first GPU's. ________________________________ From: Sebastian Sylvan [mailto:sebastian.sylvan@gmail.com] Sent: den 4 november 2008 20:06 To: sveina@gmail.com Cc: Tobias Bexelius; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Memory efficiency questions for real-time graphics On Mon, Nov 3, 2008 at 3:45 PM, Svein Ove Aas wrote: On Mon, Nov 3, 2008 at 11:31 AM, Tobias Bexelius wrote: > 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 :) > Or you could use OpenGL, which has supported that since the first GPUs that did were released. I think that came with OpenGL 3.0. Unless you're counting vendor-specific extensions... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

6041

Age (days ago)

6044

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Don Stewart
Sebastian Sylvan
Svein Ove Aas
T Willingham
Tobias Bexelius