Add Triton backend and basic functionality with Torch version

[ZephyrKeXiner]

Summary

This PR adds an experimental Triton packed-bitmask path for large GreedyNMM + IOS postprocessing workloads.

The current torchvision backend computes a dense N x N IoU/IoS matrix on GPU and copies the whole float32 matrix back to CPU before running the greedy merge loop. For large sliced-inference workloads with thousands of boxes, this GPU-to-CPU transfer can become expensive.

And

For GreedyNMM, the greedy loop only needs the thresholded pairwise match result:

IOS(i, j) >= match_threshold

It does not need the exact float IOS value after the threshold check. This PR uses Triton to compute the thresholded IOS matches directly and packs them into a uint32 bitmask.

What Changed

• Added a Triton backend path for GreedyNMM + IOS.
• The Triton kernel outputs a packed bitmask with shape:

N x ceil(N / 32)

• Added CPU greedy merge logic that consumes the packed bitmask while preserving the original keeper/suppression order.
• Kept Triton manual/experimental for now; auto does not select Triton by default.
• Added benchmark coverage for:
  • numpy
  • torchvision_matrix
  • torch_mask
  • triton

Why This Helps

The origin implement transfer the N x N IoU/IoS matrix from GPU to CPU, it will cause huge memory bandwidth cost. So it comes out that whether we can only transfer a expression of the GPU result?

The greedy algorithm itself is still executed sequentially on CPU. The speedup comes from avoiding dense matrix materialization/transfer and using a compact bitset representation.

Benchmark

Benchmark target:

GreedyNMM + IOS
class-agnostic
synthetic clustered boxes

The synthetic benchmark is model-free on purpose. It isolates the ndarray-level postprocess step after sliced inference has already produced many boxes.

Environment:

GPU: NVIDIA Tesla T4
torch: 2.8.0+cu128
torchvision: 0.23.0+cu128

Median latency:

boxes	numpy	torchvision matrix	torch bool mask	Triton packed bitmask	speedup vs matrix
1,000	41.6 ms	10.4 ms	4.1 ms	8.7 ms	1.2x
2,000	91.6 ms	30.7 ms	14.8 ms	10.0 ms	3.1x
5,000	587.8 ms	173.1 ms	40.4 ms	29.3 ms	5.9x
10,000	2249.4 ms	618.5 ms	188.9 ms	73.1 ms	8.5x

Parity with NumPy was preserved for all benchmark cases.

and on

GPU: NVIDIA RTX 2080 Ti * 2
torch: 2.8.0+cu128

It even has 10x improvement.

Notes

• This mainly targets large GreedyNMM + IOS workloads.
• It is not expected to help small inputs as much.
• NMS + IOU is not the target here because torchvision already has a native optimized NMS kernel.
• The Triton path currently shows higher variance in some larger cases, so I kept it experimental/manual for now.
• I would appreciate feedback on whether this should stay as a separate experimental backend or be integrated behind an input-size threshold.

[ZephyrKeXiner]

The package triton is only available on Linux and Python >= 3.9, so the tests on Windows, macOS and Python 3.8 fails instead of the code error.