[Fix] Fix arf op's write conflict when num_orientations is not 1

[dflhw]

Motivation

1. When num_orientations is not 1, the calculation result of active_rotated_filter op on cpu is inconsistent with that on cuda.
2. Issue link: 2718，the modified code can pass the sample test.
3. This change does not affect scenarios where num_orientations is 1.

Modification

Indexes are added to prevent data from being written to only the first feature map.

BC-breaking (Optional)

Does the modification introduce changes that break the backward-compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Checklist

Before PR:

• I have read and followed the workflow indicated in the CONTRIBUTING.md to create this PR.
• Pre-commit or linting tools indicated in CONTRIBUTING.md are used to fix the potential lint issues.
• Bug fixes are covered by unit tests, the case that causes the bug should be added in the unit tests.
• New functionalities are covered by complete unit tests. If not, please add more unit test to ensure the correctness.
• The documentation has been modified accordingly, including docstring or example tutorials.

After PR:

• If the modification has potential influence on downstream or other related projects, this PR should be tested with some of those projects, like MMDet or MMCls.
• CLA has been signed and all committers have signed the CLA in this PR.

[grimoire]

Hi, Thanks for the PR.
Actually, I am a little bit confused with this OP.
Let's say, if two threads have the same i, j, k, idx (and fmIndex) and different l. They will store different val to the same target. That does seems not make sense.
I will try to contact the origin repo owner to see if it is a bug.

[dflhw]

Hi, Thanks for the PR. Actually, I am a little bit confused with this OP. Let's say, if two threads have the same i, j, k, idx (and fmIndex) and different l. They will store different val to the same target. That does seems not make sense. I will try to contact the origin repo owner to see if it is a bug.

Hi, Thanks for your reply.
To ensure that every input value is taken, the values of indices here are combinations of permutation of 1 to kH * kW.
Keep i, j, k have the same value. When num_orientations is 1, the value range of l is 1 to kH * kW. In this case, the value of idx ranges from 1 to kH * kW, there is no write conflit.
But when num_orientations is 2(or other num), the value range of l is 1 to 2 * kH * kW, the value range of idx is still 1 to kH * kW. So the value range of l is kH * kW to 2 * kH * kW will write to the same address as 1 to kH * kW. In this case, it is need to add kH * kW to idx.
If num_orientations is 3, it is need to add kH * kW to idx when the value range of l is kH * kW to 2 * kH * kW and add 2 * kH * kW to idx when the value range of l is 2 * kH * kW to 3 * kH * kW.

[grimoire]

Can I assume elements of indices[oir_id, :, :, rot_id] are shuffle of arange(kH * kW), and each element is unique? I have no rotation detection background.

PS: bank conflict is a term that is widely used to describe shared memory visit problems in CUDA. I think retitling this PR would be cool to avoid Ambiguity.

[dflhw]

Can I assume elements of indices[oir_id, :, :, rot_id] are shuffle of arange(kH * kW), and each element is unique? I have no rotation detection background.

PS: bank conflict is a term that is widely used to describe shared memory visit problems in CUDA. I think retitling this PR would be cool to avoid Ambiguity.

Yeah, I think it is.
It seems that in this operator, in order to rotate a certain angle, there is a certain order of the indices[oir_id, :, :, rot_id].
Thanks for correcting the title, I will edit it.

[grimoire]

LGTM

[dflhw]

LGTM

Sorry, I misunderstood the use of indices，it seems that indices[:, :, :, rot_id] is permutation of arange(num_orientations * kH * kW), so the usage of indices in issue 2718 is wrong, it is not a bug, this pr should be reverted.

refer to: mmrotate orconv.py