From: Manfred Weiler (Manfred.Weiler@informatik.uni-stuttgart.de)
Date: 12/05/2000 11:28:01
Hi Dave,
thanks for the interesting insight into the volumizer internals.
> Interleaving is somewhat complicated. ;) By default, the API will simply
> allocate a new array and copy the data, then free the previous two
> pointers. However, if it sees that the two bricks being interleaved are
> allocated from contiguous memory regions, it will attempt to perform
> "in-place" interleaving. (The two pointers are concatenated together and
> treated as one, minimizing fragmentation of memory.) Once the
> volumeOptimize() method has interleaved the data, the data pointers for
> both bricks are updated to point to the interleaved data. So it is indeed
> possible to access the interleaved data directly.
Did I get this right, also in the case of external brick data, volumizer
deletes the old brick memory? Freeing memory that has been allocated by
the user?
Quite naughty ;-) You wouldn't actually expect such behaviour.
In addition to that this is a source of severe program errors.
What about the original pointer, the memory chunk was assigned to,
normally a good programmer would try to free the memory adressed by
this pointer. Volumizer also doen't know how the memory was allocated
using ,,new'' or ,,alloc'' or whether the pointer that was given to
a brick points to the beginning of an allocated memory block at all...
> > > If you're willing/able to keep two copies of your data in physical
> > > memory - one for Volumizer and one for the rest of your app, then that
> > > would be the best solution. Otherwise you can try to make things work by
> > > bricking only in Z and making sure not to interleave the data.
> >
> > But that would mean one would have to copy the whole volume data
> > or at least brick data whenever even a single voxel changes.
> > That can't be really fast.
>
> Why would you need to copy the whole volume data when a single voxel
> changes? You would merely be allowing Volumizer to keep its own internal
> representation of the data, separate from your application's data. Every
> time you modify a voxel in your application, you would need to:
>
> a) update your own data structures
> b) update Volumizer's data structures. This is simple, since we have
> provided a number of voxel modification convenience methods that correctly
> handle interleaving and bricking.
>
> The disadvantage, of course, is that you are consuming twice the memory -
> and that you will have to make modifications to both representations every
> time something changes. But it would allow you to take advantage of any
> bricking strategy easily and to use texture interleaving to improve
> performance.
>
> Regarding the performance of getVoxelAddr(): It is a convenience routine
> that determines the address of a voxel given its coordinates. It must
> correctly take into account interleaving and bricking to make this
> determination. For applications whose performance is gated by the speed of
> many reads of voxel data, this is not as efficient as simply performing
> pointer arithmetic on individual bricks.
The question came up from Matthias posting. He complained about the poor
performance of using "getVoxelAddr". As I got the point this is only due
to a little bit more of pointer arithmetic that has to be done by this
methode compared to directly accessing the memory. And in addition to that
getVoxelAddr first has to find the brick a voxel is contained in - which
might impose most of the overhead I suppose ?
So we can guess Matthias does access a lot of voxels in his
volume modifications or otherwise he would not suffer from poor
performance?
For this situation you propose a copy of the volume data for fast access
in case of voxel read and to perform voxel writes on the internal brick
data and for consistency reasons on the external copy as well?
For writes into brick memory you propose setVoxel()/setSubVolume()
depending on the number of voxels that have been modified.
Wouldn't it be an even better idea to perform all volume data modifications
brick by brick. I guess voBrick::getVoxelAddr should be quite fast for
there are much less indirections than using voBricksetCollection::getVoxelAddr
an the pointer arithmetic of voBrick::getVoxelAddr can hardly be more
expensive than working directly on the data array. At least it shouldn't.
So you can save memory and perform voxel modifications in place.
O.K. the method of choice will depend on what exactly you want to do
with your volume data. Unfortunately Matthias did not go into details
of his task.
Manfred.
-- ====================================================================== Manfred Weiler Manfred.Weiler@informatik.uni-stuttgart.de Visualisierung und Interaktive Systeme Telefon: 0711/7816-208 Universitaet Stuttgart, IfI FAX: 0711/7816-340
This archive was generated by hypermail 2b29 : Tue Dec 05 2000 - 13:07:14 PST