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.:
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.
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.
This is in the programming guide -mul24 is 4 cycles vs. 16 for a full 32-bit mul.
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!!
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.