При каких условиях Металлический шейдерный код "crash?"

Question

Я разрабатываю приложение на основе металла, а в некоторых случаях правильно скомпилированный и связанный шейдерный код приведет к простому сбою приложения без каких-либо ошибок.

«Сбой» состоит из остановки визуального вывода (в некоторых случаях предшествует короткое заикание пары чередующихся кадров), но в остальном нормальное шествие остальной части приложения. Утилиты мониторинга производительности Xcode сообщают 60 кадров в секунду, но 0 мс латентности графического процессора, а исполнение на стороне процессора продолжается, а вызовы Metal API все еще успешно завершаются.

На консоль не сообщается никаких ошибок.

Это очень сложно отлаживать, поскольку у меня нет указаний на то, где в шейдерном коде возникает ошибка. Это помогло бы, если бы я знал, при каких условиях это должно произойти, чтобы у меня был хороший список вещей для проверки. В противном случае я просто стреляю в темноте, когда это возникает.

Answer 1

Графический процессор может быть поврежден, когда вы читаете или списываете конец MTLBuffer, сбрасываете конец MTLTexture или просто запускаете слишком долго. Существует сторожевой таймер, который сбросит GPU, если он не завершит свою работу менее чем за несколько секунд. Работа с графическим процессором не выполняется заранее. Возможно, что при длительной работе устройство блокируется, предотвращая выполнение основных задач GUI. Если у вас есть длительные рабочие нагрузки, необходимо разбить его на несколько меньших ядер. Чтобы поддерживать отзывчивость интерфейса, вы должны сохранять рабочие нагрузки < 100 мс. Во избежание заикания видео рекомендуется согласованная частота кадров.

Answer 2

У меня были частые сбои из-за тяжелых металлических шейдеров, а также исправлены, чтобы исправить это, регулируя скорость отправки. Вы можете сделать это легко, измеряя время выполнения последнего «кадра», и вставляя ждать перед каждой отправкой в ​​соотношении от этой суммы:

[NSthread sleepFortimeInterval: _lastRunTime*RATIO]; 
NSDate *startTime = [NSDate date]; 
... [use Metal shaders] ... 
_lastRunTime = -[startTime timeIntervalSinceNow]; 

Я установил RATIO 1.0. Таким образом, он никогда не использует более 50% gpu. Это, очевидно, влияет на частоту кадров, но превосходит случайные сбои. Вы можете играть с коэффициентом. Приятно, что вам не нужно беспокоиться о том, чтобы слишком сильно или слишком мало воздействовать на разные продукты, так как это соотношение времени выполнения.