Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limitations on Spatially Partitioned Messaging dimensions #63

Closed
ptheywood opened this issue Apr 25, 2017 · 1 comment
Closed

Limitations on Spatially Partitioned Messaging dimensions #63

ptheywood opened this issue Apr 25, 2017 · 1 comment
Labels

Comments

@ptheywood
Copy link
Member

Windows imposes limits on the size of statically allocated data. For 32bit and 64bit windows this is limited to 2GB (source).

The number of bins required for spatially partitioned messaging is dependant upon the bounds and radius. If the combination of environment bounds and radius result in a significant number of bins being required (approx 536,870,912 bins, or roughly an 812*812*812 cube ) then the application will not compile.
This should not be a problem for FLAMEGPU2 as dynamically allocated memory can be up to 8TB on Windows x64.

Furthermore, the use of cudaBindTexture in spatially partitioned messaging imposes an additional limit (device dependant) at runtime.
The total number of elements in a linear address range cannot exceed cudaDeviceProp::maxTexture1DLinear[0] (source), which for a Geforce GTX Titan X is 134217728 texels (source).
In practice this limits the number of bins in spatially partitioned messaging to 512*512*512.

@mondus
Copy link
Member

mondus commented Apr 25, 2017

Great spot. A bin with 512*512*512 would require 1GB of memory anyway so chances are that any model would be close to reaching memory limitations. Still can be fixed in version 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants