Replaces atomicAdd accumulators in `ppo_clipped_surrogate_fwd` and
`dqn_distributional_q_bwd` with per-batch [B] outputs + a dedicated
single-block tree-reduce kernel. Per feedback_no_atomicadd.
Root cause: `ss_pi_loss_dev_ptr` was zero-init at trainer construction
but never reset between steps; the PPO atomicAdd accumulated across
every step since startup. Result: `loss.pi` = step_count × mean_per_step,
bit-exact step-count fingerprints:
- local 1k × ~9 ≈ 9080 ✓
- cluster 20k × ~1200 ≈ 24M ✓
The DQN distributional Q kernel had the same atomicAdd pattern. Its
trainer caller happened to memset between launches in dqn_replay_step
so the symptom was masked, but the anti-pattern was identical. Fixed
in the same commit per the user's "atomicAdd should not be used at all"
reminder.
Local smoke (RTX 3050, b=16, 1k steps, seed=16962):
step | l_pi (pre → post) | l_q (pre → post)
100 | 27.5 → 0.56 | 18.1 → 0.19
500 | 743.1 → 4.59 | 93.3 → 0.19
999 | 9080.5 → 65.1 | 186.1 → 0.19
l_q now bit-flat at per-step mean (~0.19) — no step-count fingerprint.
l_pi grows organically with policy excursion (PPO surrogate magnitude
when ratio→clamp_max under Q-distillation-driven policy updates),
which is the legitimate diagnostic the prior staleness was burying.
Changes:
- ppo_clipped_surrogate_fwd: scalar [1] outputs → per-batch [B]
- dqn_distributional_q_bwd: remove atomicAdd; per_batch[B] only
- ppo_loss_reduce_b.cu (NEW): two block tree-reduce kernels
• ppo_loss_reduce_b (dual: PPO loss + entropy loss)
• mean_reduce_b_f32 (single, reused by DQN head)
- PolicyHead + DqnHead: load reducer cubin, add reduce_loss_to_scalar
- Trainer: allocate ss_pi_loss_per_b_d + ss_pi_loss_entropy_per_b_d,
invoke reducer after each backward (PPO + DQN replay paths)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
7b3309edcc