Оптимизация VR графики с поздней фиксацией

02.03.2015 857 0

Атман Бинсток

Атман главный архитектор в Oculus и технический директор в Rift. До присоединения, он был одним из ведущих инженеров и движущей силой VR проекта Valve, создавая демо ‘VR Room‘, которое получило большой ажиотаж на Steam Dev Days. ДоValve, Атман провел несколько проектов в ведущих промышленных компаниях, включая RAD, DICE, и Intel.

TLDR: Оптимизация графических VR является проблемой, как правило, с наличием компромиссов между качеством, временем ожидания и производительностью. Тем не менее, использование поздней фиксации напоминают бесплатный сыр в мышеловке: повышение производительности GPU без увеличения времени ожидания. Как мы обсудим, это на самом деле не бесплатно, но мы пытаемся улучшить ситуацию.

Почему минимизации задержек движения к фотону имеет решающее значение для комфортного взаимодействия в VR, которая была хорошо изучена во многих других работах (см в блоге Майкла Абраша). В этой статье мы поговорим о том, как поздняя фиксация может быть использована для уменьшения времени ожидания графического конвейера VR.

В течение многих десятилетий, 3D компьютерная графика была оптимизирована для увеличения пропускной способности с небольшими проблемами в сфере времени ожидания. Это нашло свое отражение в глубокой конвейерной архитектуре в современных GPU, драйверов и ОС. Для того, чтобы сохранить максимальное использование GPU ресурсов, приложение работает хорошо перед GPU, с команды буферизации, иногда в несколько этапов перед выполнением. На современной машине Windows, это может повлечь за собой до трех кадров латентности в графическом конвейере, даже не считая В-приложение, конвейерную задержку или задержку отображения.

1

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

В первой строке время в миллисекундах. Этот гипотетический дисплей 100 Гц.

Вторая строка vblank событий, которые происходят каждые 10 мс.

Далее идет отслеживание сроки — это показывает «ПО» в мс, указывая, что положение и ориентация были отобраны по приложением.

Приложение CPU график показывает, что активная, отбор проб ставить и оказания с мс 0 до 7.

Ниже находится GPU график, показывающий два кадра предыдущие кадры (MS 6-13 и 14-21), а затем наш текущий кадр из мс 22 до 28. В мс 29 искажений / деформации проход выполняется на GPU.

Далее идет флип график, показывающий в мс 30 кадров.

Последние две строки показывают полные положения и ориентации задержки: оба были испробованы в мс 0 и отображаются в мс 30, который является 30 мс латентности.

Простой Synced VR Графический конвейер

Такого рода задержки является неприемлемыми для VR, таким образом простейший способ борьбы с ними, чтобы защитить процессор от управления  GPU. Один из способов сделать это путем синхронизации процессора и GPU каждый фрейм, как правило, сразу после VSync. Это может быть достигнуто с событиями или буферных замков, чтобы заставить камерной передачи данных.

engine::Render(pose);
vr::RenderDistortion();
gfx::Present();
gfx::GpuSync();

[Отказ от ответственности: Ни один из фрагментов кода не являются реальными, и они не отображаться на API Oculus; они просто предназначены, чтобы показать координации между двигателем, VR SDK, а графика API.]

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

Недостатком этой простой синхронизированной транспортировки можно считать значительное снижение использование графического процессора. После окончания проход искажения, GPU простаивает до и после VSync, где CPU начинает питать его снова. И CPU / GPU параллелизм стирается: в случае, однопоточных игр (те, которые делают игру-обновление и визуализации на том же потоке) внушительно деформируют, как GPU будет полностью простаивать во время обновления игры. Это также делает производительность более уязвимой, так как у нас меньше запас, чтобы поглотить проблемы с производительностью, введенные распределения потоков управления буфером управление, а также множество других, не детерминированных факторов на современном компьютере.

Ограниченный QueueAhead

pose = vr::SamplePose();
engine::Render(pose);
vr::RenderDistortion();
gfx::Present();
gfx::GpuSyncToPreviousFrame();

Так что, если мы позволим CPU бежать впереди всего на один кадр?

Можно было бы использовать дополнительный кадр задержки для повышения CPU / GPU параллелизма и использованияGPU. Заманчиво, не так ли? К сожалению, мы уже знаем, результат этого: дополнительная задержка, тем меньше комфортно и убедительным VR во многих ситуациях.

Late-Latching

Что делать, если мы могли бы иметь преимущества работ в случае без оплаты с дополнительной задержкой? Звучит слишком хорошо, чтобы быть правдой, не так ли? Ну, это не совсем бесплатный сыр в мышеловке, но это довольно близко.

Основная идея проста и была вокруг всегда: уменьшить задержку входного сигнала, имеющего побочный канал, что обеспечивает вход в конвейерную графическую систему. Это было использовано в нескольких поколениях консолей, где строгие требования упорядочения ПК API, не нужно брать во внимание. Это также предварительные даты современной 3D-графики в виде аппаратных курсоров мыши.

Когда мы в очереди добро, мы должны управлять передачей кадра, находясь в различных буферных элементах с начала отслеживания представляют, что становится все более устаревшим по миллисекундам. Что делать, если мы могли бы просто нажимать на обновления команды, которые были выполнены на GPU? Это в основном то, что в конце-фиксации: мы каналы Обновленная ветвь отслеживания представляет данные в GPU по боковому каналу и имеет GPU первичную «защелку» этого положения данных перед выполнением команд, которые составляют каркас.

«Защелка» здесь означает атомарно скопировать из постоянно обновляемых представляют данные в частный буфера для последующего использования. Фактические механизмы, вовлеченные в обновление и фиксацию побочного канала не будут обсуждаться здесь, как они могли бы составить полный пост в блоге самостоятельно.

Простейший способ добавить в конце фиксации в очереди перед транспортировкой к концу фиксации ориентации для поворота основы в конце кадра. Это может быть сделано более или менее понятным в графическом редакторе.

В этом примере, EnqueuePoseLatch представляет команду GPU, который при выполнении будет принимать последнее обновление и отслеживания. RenderDistortionLateLatchedWarp использует этот буфер, применяя деформацию на основе данных фиксируется ориентация.

Интересная часть происходит в мс 17: после GPU делает кадр, он выполняет latelatching. Зафиксированное значение ориентации затем используется основы в мс 18. Это уменьшает задержку ориентации Возврат к 3 мс — примерно то, что это было в latewarped передачи.

Тем не менее, время ожидания по-прежнему значительно выше. Мы можем оптимизировать это, в  latelatching тоже, хотя это не будет так просто:

Теперь GPU сроки, мы с фиксацией положения на мс 9, прямо перед GPU начинается оказание кадр. Положение фиксации должно произойти перед кадром, потому что рама делают, зависит от этой позиции. В отличие от ориентации, нет простой 2D основы, чтобы исправить вверх позицию после рендеринга. К счастью, людей можно изменить положение гораздо медленнее, чем они могут изменить вращение, так что это дополнительная задержка, кажется, разумный компромисс.

Подождите, код выглядит довольно просто! Ну на самом деле, этот код обманывает немного и скрывает кучу сложностей. Во-первых, обратите внимание, что для всех реальных графических элементов нужно сделать выбраковку и т.п., так по крайней мере нужно:

cull_pose = VR :: SamplePose ();

latched_pose_buffer = VR :: EnqueuePoseLatch ();

Двигатель :: Render (cull_pose, latched_pose_buffer);

latched_warp_pose_cb = VR :: EnqueuePoseLatch ();

VR :: RenderDistortionLateLatchedWarp (latched_warp_pose_cb);

GFX :: Present ();

GFX :: GpuSyncToPreviousFrame ();

И это указывает на реальную сложность положения latelatching: фактические конечные результаты (они же вид матрицы) не доступны для процессора, когда графическое ядро ​​работает, чтобы сделать кадр. Это влечет за собой несколько последствий:

  • Код процессора не может использовать матрицу вида непосредственно в любом случае. Например, объединения моделируемую матрицу вида или установление вида пространственного освещения.
  • Следовательно, процессор не может напрямую отправить матрицу вида к любому шейдеров. Вместо этого, существуетEnqueuePoseLatch () очередь команд, чтобы закончить процесс последнее подает в буфер GPU latched_pose_buf и последующие команды визуализации должны использовать этот буфер (или буфер, полученный от него), чтобы получить матрицу вида.

Это означает, что потенциально любой шейдер, который использует матрицу вида (или какие-то производные от нее), или работает в видимом пространстве должен быть преобразован. Для комплексной современной системы, это может быть нетривиальное количество технических элементов. Мы активно воплощаем этот подход с Unity и Unreal, а также поддержку в будущем SDK для пользовательских систем.

Кроличья нора

Возникает целый ряд вопросов о latelatching, по этой причине мы не можем прийти к цели. С одной стороны, есть трудность в том, чтобы заставить его работать на текущем ОС, на различных аппаратных средствах в реальности. Кроме того, есть множество вопросов, по кадровой синхронизации. А кроме всего прочего глубокая кроличья нора: как оказалось, опережает игровой код!

Выводы

Создание крупной VR требует много тяжелой работы и сотрудничества между всеми игроками в экосистеме. Мы делимся прогрессивными результатами в latelatching, наряду с другими исследованиями VR, поощряем ведущих GPU компании, какAMD и NVIDIA, чтобы принимать и продвигать изучаемые методы. Все технологии (приложение, SDK, ОС, драйвер) должны хорошо работать, чтобы доставить большой опыт и знания VR — потому что это очень важно для успеха VR, мы нуждаемся в поддержке GPU и ОС, чтобы сделать его реальностью.

Оптимизация VR графики является проблемой, как правило, с наличием компромисса между графическим качеством, временем ожидания и производительностью. И это часто кажется игрой с нулевым результатом, где вы выигрываете в одном измерении только понеся потери на других. Тем не менее, данная система помогает получить что-то ничего: мы можем оптимизировать время ожидания или производительность (в зависимости от того, где вы начали), не отказываясь от качества.VR это магия опыта;  latelatching позволяет доставить больше магии лишь с некоторыми кодирования — это не совсем бесплатный сыр в мышеловке, но, надеюсь, довольно внушительно.

— Атман Бинсток, главный архитектор


Добавить комментарий

Ваше имя *
Ваш email
Комментарий

0
Товар успешно добавлен в корзину.