[vtk-developers] vtkGPUInfo and large amounts of memory

[David Thompson]

> If you need more than 2^32 bytes of memory, you likely need to build VTK as 64-bit anyhow, in which case, vtkIdType defaults to a 64-bit wide type, too... So is a change really necessary?
> 
> Or..... you *can* build a 32-bit build of VTK, but explicitly set its id type to be 64-bits anyway, even in the 32-bit build.
> 
> I'm not sure I see the advantage of using size_t over vtkIdType, as they both vary in size based on CMake/compiler settings.
> 
> Can you elaborate on why you think it would be better to use size_t instead of vtkIdType?

Well, to be a contrarian, I think both those options are guilty of mixing metaphors:

- vtkIdType is meant to hold IDs, not pointers or pointer offsets. For people using unstructured grids as opposed to image data, a 32-bit cell ID may be fine and the name of the type does not imply that it will be used as a pointer offset, so they may not be in the right frame of mind to realize what the problem is when their GPU memory is misreported. Those people might still want to know how much memory is on the GPU if they want to render to large textures, for instance.

- If the class weren't named vtkGPUInfo, size_t would be appropriate since it is meant to serve as a pointer offset. But the GPU drivers could potentially be built to expose more memory than the host system libraries are configured to address, so it is also (just barely) misusing a typedef.

- Why not use vtkTypeInt64? That is what it's there for. Then there is no chance that the memory will be misreported until vtkTypeInt128 is required. I doubt anyone is going to use vtkGPUInfo in a tight loop, so the overhead is negligible. Developers who don't have to hunt down why GPU memory is being misreported on some weird system their uncle's friend uses for his collection of cat X-rays will be happy you chose vtkTypeInt64.

- Another alternative is to report GPU memory in saner units, like kiB or MiB.

- That's the Good and the Bad. The Ugly would be to report memory as a double, which has a 53-bit mantissa. But then someone would surely ask how to access the fractional bits. :-)

	David