У меня есть две проблемы в приложении Metal.
- Мой звонок на
currentPassDescriptor останавливается.Очевидно, у меня слишком много рисованных объектов. - Я полностью сбит с толку, как большинство оперативно настраивает несколько
MTKViews, которые я использую.
Issue (1)
У меня проблема с currentPassDescriptor в моем приложении.Иногда это блокировка (на 1,00 с), которая, согласно документам, объясняется отсутствием currentDrawable.
Справочная информация: у меня одновременно воспроизводится 4 видео HD 1920x1080, выложенных на 3840x2160 секунду внешнегоотображать как конфигурацию отладки.Пиксельные буферы этих AVPlayer экземпляров захватываются 4 независимыми CVDIsplayLink обратными вызовами, и из обратного вызова происходит вызов отрисовки для назначенного MTKView.В общей сложности 4 MTKViews являются подпредставлениями, выложенными плиткой на одном NSWindow, и настроены для рисования вручную.
Я использую CVDisplayLink обратные вызовы вручную.Если это не так, то я заикаюсь, когда копаюсь в меню приложения, например.
В каждом вызове отрисовки я выполняю небольшую работу с шейдером ядра, затем пытаюсь получить currentPassDescriptor.В случае успеха я делаю один проход фрагментного / вершинного шейдера, а затем представляю прорисовку.Мой поток кода соответствует образцу кода Apple и опубликованным примерам.
Согласно Metal System Trace, большинство вызовов отрисовки занимают менее 5 мс.GPU используется примерно на 20-25%, и около 25% свободной памяти GPU.Я также могу вызвать основной поток на usleep() в течение 1 секунды без каких-либо отклонений.
Без какого-либо взаимодействия с пользователем вероятность того, что видео сработает в первую минуту, составляет около 5%.Если есть какая-то работа с пользовательским интерфейсом, то я вижу, что windowServer работает в Инструментах.Я также отмечаю, что AVFoundation, по-видимому, кэширует около 15 кадров видео на GPU для каждого AVPlayer.
Если частота вызовов на отрисовку нарушена, вероятность того, что все закончится, составляет 10%.или некоторые из видео - некоторые полностью остановятся, некоторые остановятся с обновлениями 1 Гц, некоторые вообще не остановятся.При запуске Metal System Trace также меньше шансов на зависание.Фильмы, которые остановились, похоже, сделали это при получении currentPassDescriptor.
Это действительно плохой дизайн, чтобы иметь этот currentPassDescriptor блок в течение ≈1 с во время цикла рендеринга.Настолько, что я думаю о том, чтобы полностью отказаться от MTKView и просто нарисовать CAMetalLayer сам.Но документы по CAMetalLayer, кажется, указывают на то, что произойдет то же самое поведение блокировки.
Я также на ходу собираю эти 4 пиксельных буфера и рендерирую интересующие области меньшего размера до 4 меньших MTKViews наосновной монитор;но заикание все еще происходит, если этот код удален.
Ограничен ли размер буфера для рисования на MTKView или на основе CALayer? Документы для maximumDrawableCount на CAMetalLayerскажем, число должно быть 2 или 3. Этот вопрос связан с конфигурацией представлений.
Issue (2)
Моя текущая настройка - 3840x2160 NSWindow сединое содержимое просмотра.Этот подкласс NSView делает некоторое скрытие / обнаружение курсора мыши, вводя NSTrackingRectTag.MTKViews являются плиточными подпредставлениями в этом представлении содержимого.
Это лучшая конфигурация? А именно, один NSWindow с плиточным MTKViews… или я должен сделать один MTKViewза окно?
Я также не уверен, как лучше настроить эти окна / слои - т.е.установив (или очистив) wantsLayer, wantsUpdateLayer и / или canDrawSubviewsIntoLayer.В настоящее время я просто устанавливаю wantsLayer на ДА в одном представлении содержимого. Любые намеки на это были бы хорошими.
Сглаживает ли настройка этих свойств все доступные элементы рисования только для заднего слоя;есть еще 2 или 3 на MTKView?
Примечание: я имею отношениеПридумал пробный прогон моего приложения Metal.Самая длинная «работа» на верхнем графике составляет чуть менее 5 мс.Зеленые / синие скопления рендеринга на 4 MTKViews.«Работа» немного чередуется, потому что одно из видео является источником 60fps;остальные 30fps.
