GPU Design · All levels
GPU Programming Model & SIMT: Tricky Q&A
Senior interview and review questions for GPU Programming Model & SIMT.
Section Q&A bank
Use these drills after completing all topics in GPU Programming Model & SIMT. Answer with workload context, mechanism proof, artifact, owner, and release decision.
Why does higher theoretical occupancy sometimes reduce kernel throughput?
diagram
[INT][GPU][GPU-PROGRAMMING-MODEL]
Q: Why does higher theoretical occupancy sometimes reduce kernel throughput?
A:
Extra residency can increase register pressure and shared-memory contention, creating more spills and scheduler stalls than the additional warps can hide.
FOLLOW-UP TRAP: Treating occupancy as an always-increasing performance knob.How do you quickly separate SIMT divergence from memory inefficiency?
diagram
[INT][GPU][GPU-PROGRAMMING-MODEL]
Q: How do you quickly separate SIMT divergence from memory inefficiency?
A:
Check branch efficiency with lane-mask traces first, then compare transaction inflation and coalescing counters on the same workload slice.
FOLLOW-UP TRAP: Blaming divergence without lane-mask and memory evidence together.What is the first sign that launch geometry is mis-sized for an SM?
diagram
[INT][GPU][GPU-PROGRAMMING-MODEL]
Q: What is the first sign that launch geometry is mis-sized for an SM?
A:
Low eligible warps per cycle combined with underfilled residency despite high launch dimensions indicates resource-bound blocks.
FOLLOW-UP TRAP: Using grid size alone as proof of good SM utilization.When should thread-block shape be revisited before algorithm changes?
diagram
[INT][GPU][GPU-PROGRAMMING-MODEL]
Q: When should thread-block shape be revisited before algorithm changes?
A:
When profiler data shows latency-hiding deficits from register/shared-memory limits rather than arithmetic pipeline saturation.
FOLLOW-UP TRAP: Changing algorithm logic before validating launch-shape bottlenecks.Q&A drill guide
diagram
WORKLOAD -> BOTTLENECK -> METRIC -> CHANGE -> REGRESSIONSketch while answering
diagram
PROGRAMMING MODEL STACK
host API -> kernel launch -> grid -> block -> warp -> laneKey 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.