fix(grouped_gemm): initialize Xe2 scheduler counter before launch

[SergiioB]

Purpose

Initialize the Xe2 grouped-GEMM persistent scheduler counter before launching the kernel, and remove the now-redundant in-kernel zero store.

The previous initialization was performed only by work-group 0, local thread 0. There is no device-wide barrier before other work-groups execute atomicAdd, so another work-group can observe stale state, or a late store can reset a counter that has already been incremented.

Using at::zeros queues initialization before the grouped-GEMM launch. The in-kernel atomic_ref::store(0) is removed as requested in review. The local barrier after each work-group obtains a scheduler ticket remains unchanged.

The paged-decode tuple originally included in this PR was cherry-picked and merged separately in #526. This PR is now rebased onto that commit and contains only the grouped-GEMM fix.

Performance consideration

Although the buffer is one int32, at::zeros may add a fixed dispatch/dependency cost, most visible for small grouped-GEMM calls. Removing the in-kernel store avoids paying both initialization paths. This PR does not claim zero overhead without a matched measurement.

Test plan

• Existing Xe grouped-GEMM unit-test matrix on BMG/PVC CI.
• Repeated-call correctness and XPU graph replay validation.
• End-to-end eager and graph-replay latency comparison, emphasizing small-M calls.

Current validation status

• Branch rebased onto current upstream main / merged feat(attn): add paged-decode tuple 16,128,64,false,true,false #526.
• paged_decode_default.conf has no PR diff.
• git diff --check: pass.
• BMG/PVC builds and unit-test workflows were retriggered by the rewritten branch.
• Fresh graph/performance measurements are still required before making a quantitative overhead claim.

[jikunshang]

cc @Liangliang-Ma @mayuyuace

[Liangliang-Ma]

@YizhouZ @baodii PTAL at attn part

[mayuyuace]

If we change empty to zero here, please remove the zero-initialization operation in the subsequent kernel.

[mayuyuace]

And note: This change is reasonable, but it may result in a slight performance degradation.

[jikunshang]

we may need more evaluation about graph behavior.
I think it's ok to add config in separte PR. I cherry-picked in #526. will add to 0.1.13.x release.

[SergiioB]

Addressed the review comments in the rewritten branch:

• changed the scheduler buffer to at::zeros;
• removed the subsequent work-group-0 atomic_ref::store(0) block from MoEGEMM;
• retained the local barrier after atomicAdd, which is still required to publish the scheduler ticket through SLM;
• removed the paged-decode change from this PR; it is already merged via feat(attn): add paged-decode tuple 16,128,64,false,true,false #526;
• rebased onto current upstream main.

The host-side initialization provides launch ordering. The removed in-kernel relaxed store had no device-wide barrier before other work-groups reached atomicAdd, and a late store could reset an already-incremented counter.

I agree that at::zeros may add a small fixed dispatch/dependency cost even though the allocation is one int32. I have not claimed zero overhead in the revised description. The BMG/PVC workflows are running again; I will report explicit graph-replay correctness and matched small-M latency evidence rather than infer the impact.

[SergiioB]

Current status after rechecking the full thread: all recorded BMG/PVC build and unit-test jobs are green, and the paged-decode change was correctly split into merged #526. The remaining review request is still the graph-replay correctness and matched small-M latency evaluation for the host-side at::zeros initialization.

I have not produced that measurement yet, so I am not claiming the PR is ready based on CI alone. Keeping the PR open pending that evidence or maintainer direction on whether the fixed dispatch cost is acceptable.