64-bit build Error

[Evan Lezar]

Bart

I have just had a closer look at the compilation error that you spoke about over the weekend (I thought I had sorted it out).  It seems that the issue is that indices_t is a typed array of uint_t and thus the width is not explicitly set to 32bits.  Are 64bits required?  Obviously with only 32bits we limit ourselves to "only" 4 billion points (roughly) - although memory constraints are probably a much bigger problem for the time being.

Let me know whether I can go ahead and change these types to use 32bits.

Evan

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

> I have just had a closer look at the compilation error that you spoke
> about
> over the weekend (I thought I had sorted it out).  It seems that the issue
> is that indices_t is a typed array of uint_t and thus the width is not
> explicitly set to 32bits.  Are 64bits required?  Obviously with only
> 32bits
> we limit ourselves to "only" 4 billion points (roughly) - although memory
> constraints are probably a much bigger problem for the time being.
>
> Let me know whether I can go ahead and change these types to use 32bits.

If you mean "change indices_t" the answer is no ... this isn't simply a
question of how many points we can handle, uint_t is typedef'd to match
std::vector::size_type because that type is used, implicitly and
explicitly, in many calculations.  Changing indices_t would introduce lots
of warnings, casts, and errors into the code.

If using 64 bit ints with CUDA is a problem, I would suggest downcasting
to 32 on 64-bit platforms (with appropriate warnings in the code).

Cheers,
Tim



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, Jul 9, 2008 at 8:22 PM, Timothy M. Shead <tshead@...> wrote:

>> Let me know whether I can go ahead and change these types to use 32bits.
>
> If you mean "change indices_t" the answer is no ... this isn't simply a
> question of how many points we can handle, uint_t is typedef'd to match
> std::vector::size_type because that type is used, implicitly and
> explicitly, in many calculations.  Changing indices_t would introduce lots
> of warnings, casts, and errors into the code.
>
> If using 64 bit ints with CUDA is a problem, I would suggest downcasting
> to 32 on 64-bit platforms (with appropriate warnings in the code).

I think the idea is to only change the CUDA mesh structure, where all
integer arrays should consist exclusively of 32 bit number formats. As
far as I can tell this has already been done now.

Cheers,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development