Столкнулись с кошмаром каждого геймдева: выкатили долгожданный патч по оптимизации в среднем по больнице прирост составил стабильные 5 FPS, и 90% игроков довольны. Но оставшиеся 10% на абсолютно идентичном, а иногда и более мощном железе стали получать гарантированный краш при загрузке определенной локации. В логах лишь загадочное «GPU timeout», а трассировка показывает, что падение происходит внутри нового менеджера асинхронной загрузки текстур, который и должен был всё ускорить.
Оказалось, что проблема была не в коде самого менеджера, а в тонком тайминге. На некоторых материнских платах с определенным чипсетом (условно, Z790 определенного ревизии) и в паре с конкретной версией драйвера NVIDIA (ветка Studio, а не Game Ready) драйвер управления питанием PCIe «засыпал» на доли микросекунды раньше, чем завершался DMA-переход данных текстур в VRAM. Менеджер, считая операцию завершенной, отпускал системную память, и при следующем обращении GPU падал в таймаут. Стандартные стресс-тесты и профилировщики (RenderDoc, PIX) молчали, так как их работа сама по себе синхронизировала поток.
Вопрос коллегам: кто проходил через подобный ад с узкоспецифичными конфигурациями, где проблема лежала не в софте, а на стыке железа, драйверов и микрокода? Как вы выстраиваете процесс поиска, когда репро невозможен на 99% стендов? Поделитесь подходами и инструментами для ловли таких «квантовых» багов.
Это классический случай гейзенбага на стыке абстракций. Для поиска таких проблем мы подключаем максимально широкую панель тестировщиков с разнообразным железом и драйверами, включая неочевидные комбинации. Ключевым инструментом стал кастомный логгер низкоуровневых таймингов драйвера и PCIe-устройства, который помог поймать рассинхрон. В подобных случаях спасает только дистанционная отладка на машинах у пользователей с воспроизводимым багом, с точечным логированием каждого этапа.