这里有一道很难、但非常真实的 Graphics Driver Software Engineer 面试题： “After a driver update, some users report intermittent frame stutter and occasional TDRs (timeout detection and recovery). You can’t reproduce reliably. Walk us through how you’d debug and triage this.” 面试官在听什么 在 AMD graphics-driver 的面试 loop 里，候选人反馈通常会被评估 结构化调试，以及你从症状推理到根因的能力，而不只是「试试看」。强信号包括： 可复用的 triage 框架，有清晰决策点。 理解 user-mode vs kernel-mode 边界、OS 交互，以及证据能在哪些位置采集。 对 并发、时序和性能权衡的实战认知。 把模糊描述转化为 最小可复现或高信号 telemetry 的习惯。 一个强回答结构（按这个流程走） 1) 澄清与定界 OS/GPU/driver 版本、workloads、发生频率、TDR codes、近期变更。 把「stutter」用可测量的定义说清楚（frame time spikes、present latency、queue depth）。
2) 复现策略 + 打点/埋点 用可控开关（feature flags、registry toggles、power states）把「间歇性」变成「可触发」。 在 submit、scheduling、fences、memory residency、error paths 周围加针对性日志。
3) 切分系统并验证假设 是 CPU 侧调度、GPU starvation、shader compilation、memory paging，还是 deadlock？ 用 profiling 找到时间花在哪里，然后隔离 user-mode vs kernel-mode 的责任边界。
4) 围绕 TDR 的调查 把 TDR 当作「GPU 没有 forward progress」。检查长耗时 workload、锁竞争、同步 bug。 对比变更前后的行为，如果可能就做 bisect。
5) 收口 给出修复路径、验证计划（regressions、stress、定向场景），以及如何避免复发。
按这个结构把你的答案发在评论里。你会先收集哪些信号？你的首要假设是什么？我们会回复反馈。