Add sm107 tuning for DeviceRunLengthEncode::Encode

[gonidelis]

fixes part of https://github.com/NVIDIA-dev/cccl_private/issues/737

perf verification results

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 809af08b-032f-4f95-9918-6076eab42742

📥 Commits

Reviewing files that changed from the base of the PR and between 042e17c and c586c0f.

📒 Files selected for processing (1)

• cub/cub/device/dispatch/tuning/tuning_rle_encode.cuh

Included review availability: Your plan provides up to 12 included reviews per hour; 8 remain after this review.

---

📝 Summary

Summary by CodeRabbit

• Performance
  • Improved run-length encoding performance for a specific configuration using 1-byte keys and 4-byte lengths on SM107 GPUs.
  • This configuration now uses a specialized lookback processing strategy.

Walkthrough

The RLE encode tuning dispatch adds an SM107-specific branch for primitive 1-byte keys and primitive 4-byte lengths. The branch selects a tuned lookback policy and skips the general lookahead eligibility and fallback logic.

Changes

RLE encode tuning

Layer / File(s)	Summary
SM107 policy selection cub/cub/device/dispatch/tuning/tuning_rle_encode.cuh	The dispatch returns a 512-thread, 24-items-per-thread lookback configuration with direct loading, default cache modifiers, warp-scan, and no delay. It returns an empty lookahead policy for this type combination.

Suggested reviewers: miscco, bernhardmgruber

Merge Risk: ⚪ Minimal · up to c586c

This change selects a tuned lookback path for the targeted SM107 RLE encode case. No merge-blocking production or user-impact risk is currently evidenced.

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🥳 CI Workflow Results

🟩 Finished in 1h 20m: Pass: 100%/176 | Total: 1d 15h | Max: 51m 06s | Hits: 87%/191254

See results here.

[gonidelis]

This can be fishy. The huge speedups for i8 come from the lookback kernel. Given that tuning infra did explore and dind't good tunings for the most recent lookahead kernel from @nanan-nvidia.

I ran an exhaustive search over the lookahead kernel's own tuning knobs (all integral key/offset combinations) and defaults are already optimal for every measured type except for this one lane. A tuned lookback configuration still verified faster than the lookahead kernel at every problem size and run length (verification results on the internal tracking issue).

Every other type keeps the lookahead kernel, which measured as already optimal. I'm wondering if there's a structural explanation for the int8 gap

ping for ideas @bernhardmgruber