[vtk-developers] vtkGPUInfo and large amounts of memory

[Berk Geveci]

> Don't even get me started on what vtkIdType *is* correct for
> semantically... "id" to me implies something that can identify an
> object across a wide swath of operations. Since it's almost always just
> an index into some array, a vtkIdType value does not really "id"
> anything, *except* in a given container filled once with data and no
> inserts or removes allowed. Fortunately for VTK, that's the main use
> case when visualizing a large data set.

I disagree. vtkIdType is supposed to be the type of the id that identifies
things like points and cells. The fact that the most common data
structures in VTK store these in contiguous arrays is irrelevant to
the validity of the term. VTK can easily support a vtkDataSet subclass
that stores a map of (ids -> cell objects) for connectivity. The API
abstracts away the underlying storage details (for the most part).

My main issue with the current vtkIdType usage is that it is also used
to define the size of the integer used in cell arrays to refer to points. So
even if you have less than 2^31 point, you end up using 64 bits in the cell
array
to store the ids. Which doubles the storage. In my opinion, this should
be run-time configurable. Furthermore, we should use size_t when defining
offsets into these arrays, not vtkIdType. (See the Locations data member
of vtkUnstructuredGrid for example).

Best,
-berk



On Mon, Jul 7, 2014 at 9:34 AM, David Cole via vtk-developers <
vtk-developers at vtk.org> wrote:

> > "The other David"™
>
> :-)
>
>
> > To answer more directly, I
> > brought this up because I made this change the other day:
> >
> > <http://review.source.kitware.com/15924>
> >
> > and noticed the possibility of overflow.
> >
> > ...
> > ... just a size count, for which size_t seems the best type (as it's
> > what sizeof() returns).
>
> Right, but using size_t will still give you a potential overflow
> problem in a 32-bit pointer build... Shouldn't the type *always* be
> large enough to represent expected actual memory sizes encountered in
> the wild? And therefore, shouldn't it be something that's always at
> least 64-bits wide as "the other David" suggested...?
>
> Don't even get me started on what vtkIdType *is* correct for
> semantically... "id" to me implies something that can identify an
> object across a wide swath of operations. Since it's almost always just
> an index into some array, a vtkIdType value does not really "id"
> anything, *except* in a given container filled once with data and no
> inserts or removes allowed. Fortunately for VTK, that's the main use
> case when visualizing a large data set.
>
>
> David C.
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140707/3d164f29/attachment-0002.html>