PDA

View Full Version : T&L Memory Hopping, deadly or surviveable?



BlackJack
06-13-2002, 01:21 AM
I am working on a landscape engine at the moment and the idea to win speed was following:

-all fields stored on board (video memory)
-only fields which appear are updated, using
the memory region of the fields, which now
got invisible (through changing
position/viewangle)

The problem all in all is now of course, that the indexbuffer looks like following (psuedo):

138,20000,42000,3000,55000...

That it's of course far better if I had them in an order like 0,1,2.... I know too, but how I don't know how the memory management of the GPUs work... so... is this the absolute overkill or something still surviveable? The reason why I'm managing it this way is not, because I smoked something wrong too much, but simply because the memory transfer and the field calculation cost so much in the last engine, that I didn't want to do the same mistake again. On the other hand the T&L memory is of course heavily limited, so I want to save as much as possible through vertex sharing. I know that the post T&L cache can't make any use of this in my case, but I can this way save 75% memory space.

But all in all this results of course in this hopping... so... doable this way, insane this way... and if insane, does someone have a better idea how to manage a case like this one?

Michael

Julien Cayzac
06-13-2002, 01:39 AM
Originally posted by BlackJack:
That it's of course far better if I had them in an order like 0,1,2....

For cache coherent terrain indexing schemes, give a look at this paper (http://www.cc.gatech.edu/~lindstro/papers/visualization2001a/\") .

Julien.

BlackJack
06-13-2002, 08:44 AM
Well.... I read it, but all in all it's a bit unadapting to my needs. But I have found a way now I think...... I will make "groups" of 16*16 fields and will not do any sharing at all. This will in lowest LOD double my vertex count (2 polygons/field), at 8 polygons/field, it would still be 50% more, but how ever, this way it's at the end also more DirectX compatible.... where you have to know before, which regions of your VBuffer you want to change. And on the other hand makes the lightmap handling easier as well. Thanks for the link nevertheless, it was very interesting in any case.

Michael