GPU Design · All levels
Warp Scheduling & Control Flow: Tricky Q&A
Senior interview and review questions for Warp Scheduling & Control Flow.
Section Q&A bank
Use these drills after completing all topics in Warp Scheduling & Control Flow. Answer with workload context, mechanism proof, artifact, owner, and release decision.
What indicates scheduler policy mismatch rather than insufficient occupancy?
diagram
[INT][GPU][WARP-SCHEDULING]
Q: What indicates scheduler policy mismatch rather than insufficient occupancy?
A:
Large ready-warp pools with persistent unfairness and tail stalls suggest arbitration strategy, not residency depth, is the bottleneck.
FOLLOW-UP TRAP: Adding more active warps without fairness diagnostics.How do barriers become dominant even in high-throughput kernels?
diagram
[INT][GPU][WARP-SCHEDULING]
Q: How do barriers become dominant even in high-throughput kernels?
A:
Warp progress imbalance makes early-arriving warps idle at synchronization points, shrinking effective issue opportunity.
FOLLOW-UP TRAP: Assuming barriers are negligible in compute-heavy kernels.When is predication better than branching in SIMT kernels?
diagram
[INT][GPU][WARP-SCHEDULING]
Q: When is predication better than branching in SIMT kernels?
A:
When branch paths are short and divergence overhead exceeds extra instruction work from masked predicated execution.
FOLLOW-UP TRAP: Applying predication blindly to long heavy code paths.How should reconvergence behavior be validated in reviews?
diagram
[INT][GPU][WARP-SCHEDULING]
Q: How should reconvergence behavior be validated in reviews?
A:
Use lane-mask timelines and reconvergence delay counters tied to concrete branch regions in source or SASS.
FOLLOW-UP TRAP: Discussing divergence conceptually without trace-level evidence.Q&A drill guide
diagram
WORKLOAD -> BOTTLENECK -> METRIC -> CHANGE -> REGRESSIONSketch while answering
diagram
WARP SCHEDULING LOOP
ready warp? -> issue -> dependency wait -> reconverge -> issueKey takeaways
Always pair micro-kernel metrics with end-to-end workload impact.
Lock toolchain, driver, and launch metadata before comparing performance results.
Common pitfalls
Optimizing occupancy without checking memory-system saturation.
Comparing profiler captures from different driver or compiler builds.
Declaring wins without reproducible accuracy and performance gates.