The spconv version

[Orbis36]

Thanks for your work first.
My question is why your codes cannot be run on the latest SPCONV version(2.3.6).
After several days of debugging, I finally found that the spconv version you use here is weird.

For example,
If you use the .indices method to get the voxel index of the feature map backbone.
In the version you provide, the order of batch dim is increased. In this way, every batch is organized separately.
it looks like (0, x, y, z), (0, x, y, z) , (1, x, y, z), (1, x, y, z) , (2, x, y, z), (2, x, y, z)

However, from 2.2 version, the return value is out of order.
it looks like (0, x, y, z), (1, x, y, z) , (1, x, y, z), (0, x, y, z) , (2, x, y, z), (1, x, y, z)

Could you please check it?
The lastest version of spconv is much faster than 2.1 on Ampere Architecture card

[Orbis36]

This out of order problem seems will lead to the loss issues, as it will start from 60 when bs=4

[Nightmare-n]

Hi, the used version of spconv_cu111 seems to be 2.1.25 in our environment. Is it possible to sort the indices first to fix this error?

[Orbis36]

Hi, I have checked the method you mentioned. However, it seems that the loss is still very high even if the order has been sorted. Could you please check it? It's very convenient to change the spconv version and check where is the problem.

[Orbis36]

Solved, I forgot you also do 1 block of spconv in the head.
And yes, they can be solved by reorder the indices