the hash of particle example two cells have the same hash value

[shong]

Hi everyone,

I have some questions about the particle example in the CUDA SDK.

1. I am thinking about the hash of particle example. Is it possible that the diffrent cells have the same hash value?

2. the CellStarts array is only equal the number of cell numbers, is it possible that the hash value bigger than the cell numbers?

3. Is only double2 build-in the CUDA enviroment? double3, double4?

4. to what extent to use __mul24(), is it faster than the normal multuply?

I will appreciate it if anyone give the suggestion about the this questions or give some referrences.

[Simon_Green]

1. The sample code uses a simple linear hash function (and the world is finite), so it is not possible for different cells to map to the same hash value. It is possible to use more sophisticated hash functions in which multiple positions may map to the same hash value, which also has the nice side effect that the world can be unlimited, e.g.:

[url=“http://www.beosil.com/download/CollisionDetectionHashing_VMV03.pdf”]http://www.beosil.com/download/CollisionDe...shing_VMV03.pdf[/url]

2. The cellStarts array maps cell hashes to indexes in the sorted particle array, and therefore has the same number of entries as the number of cells. If you used a real hash value with 32 bits this would not be possible (too much memory), so you would have to do a binary search to find the start of the buckets.

3. There are no double3 or double4 types built-in, but you are free to implement these yourself. Presumably they were omitted because the GPU only does 128-loads natively.

4. This is in the programming guide -mul24 is 4 cycles vs. 16 for a full 32-bit mul.

[shong]

1. The sample code uses a simple linear hash function (and the world is finite), so it is not possible for different cells to map to the same hash value. It is possible to use more sophisticated hash functions in which multiple positions may map to the same hash value, which also has the nice side effect that the world can be unlimited, e.g.:

http://www.beosil.com/download/CollisionDe…shing_VMV03.pdf

2. The cellStarts array maps cell hashes to indexes in the sorted particle array, and therefore has the same number of entries as the number of cells. If you used a real hash value with 32 bits this would not be possible (too much memory), so you would have to do a binary search to find the start of the buckets.

3. There are no double3 or double4 types built-in, but you are free to implement these yourself. Presumably they were omitted because the GPU only does 128-loads natively.

4. This is in the programming guide -mul24 is 4 cycles vs. 16 for a full 32-bit mul.

Thank you very much!

[Vishu]

I have couple of questions on the particle code.

Is the sorting same as creating linked lists being done for spatial hashing? Or is it done for something else?

Basically I would like to add a new attribute to particles (ex: variable radius). It seems like to me that I should take care and make sure that is also properly sorted. Please confirm if I am right! Thanks in advance!!

[Simon_Green]

Yes, the sorting is basically a simple way to group all the particles that are in the same cell together, and allows each cell to store a variable number of particles. This serves a similar purpose to the linked list of particles you might use in a serial implementation. It also has the nice side effect of improving the texture access coherency when scanning the list.

Since the particle positions are stored as float4 values, you could store the radius in the w component for free.

[Vishu]

Yes, the sorting is basically a simple way to group all the particles that are in the same cell together, and allows each cell to store a variable number of particles. This serves a similar purpose to the linked list of particles you might use in a serial implementation. It also has the nice side effect of improving the texture access coherency when scanning the list.

Since the particle positions are stored as float4 values, you could store the radius in the w component for free.

Thanks a lot! Since I have converted your code to two dimensions, I believe I actually have two components free each on position and velocity vectors. I should be able to store upto 4 new atttributes without adding new variables.

[Vishu]

Yes, the sorting is basically a simple way to group all the particles that are in the same cell together, and allows each cell to store a variable number of particles. This serves a similar purpose to the linked list of particles you might use in a serial implementation. It also has the nice side effect of improving the texture access coherency when scanning the list.

Since the particle positions are stored as float4 values, you could store the radius in the w component for free.

Hi Simon,

I am using your particle code and I am trying to get the non-graphic-mode to run some long simulations.

At some regular intervals as the simulation runs, I would like to output some data – such as positions and velocities of all the particles. How do I access these data and output to some file?

Thanks in advance for the help!

Vishu