Здрастите. Будет много буков и картинок, потому что уж слишком много вариаций появилось графических настроек, средств исполнения и прочего и прочего, и в голове держать всё оказалось сложным. Поэтому в этой теме я буду описывать и демонстрировать лучшие варианты в контексте моего железа, чтобы в первую очередь самому определиться с настройками графики. Если у вас сходный сетап, то можете отталкиваться от моего “исследования”.
Железо
RTX 4080 16 Gb VRAM в разгоне;
DRAM 32 Gb 3600-4000 MHz;
Ryzen 5800x 8-16 core.
Монитор, разрешение 2560х1440, 165 Hz;
VR Oculus Quest 3, нативное разрешение 4128х2208, 72/90/120 Hz.
Исходные настройки графики выбираем исходя из желания иметь наиболее красивую картинку при приемлемом ФПС (От 120 для монитора и от 72 для ВР шлема):
Некоторые изначально определенные настройки
- синхронизация через g-sync на время тестов отключена, но по итогу, конечно же, включена.
- reflex не используется.
- через фильтры Nvidia выбрана резкость и донастроена экспозиция/контраст под мой монитор и глаз. Свой фильтр резкости есть и у AMD - RIS. Настоятельно рекомендую использовать.
- текстуры, тени, вода, облака на земле, разрешение эффектов, SSAO, глобальное освещение, физика, качество деформации ландшафта и дальность деревьев в максимум, остальное выставлено до той степени, когда повышение настройки не несёт визуального улучшения или наносит удар производительности.
Обращаем внимание не только на кадровую частоту, но и на график фреймрейта, картинку, загрузку ПК.
ВАЖНО: оказалось, что включенный интерфейс в DX11 съедает достаточно много кадров. Боевой интерфейс танка и самолета с СПО и радаром кушает 6-7%, интерфейс повтора кушает уже 37%. Я не знаю, было ли это до патча 2.41, тем не менее, в дх12 просадка от интерфейса гораздо меньше. Там, где дх11 просаживался на 37%, дх12 роняет фпс на 7-8%. Чтобы это явление не мешало исследованию, условимся, что все дальнейшие тесты проводим без интерфейса. Также, я не буду проводить/приводить слишком много выборок теста в одних и тех же условиях, если результат покажется мне стабильным.
Определимся с выбором DX11 или DX12. Пресет графики пользовательский, DLSS в нативе, резкость на 2 пункта + резкость через фильтры nvidia. С такими настройками картинка в достаточной степени детализированная. Можно листать стрелочками скриншоты. Первый тест в 8 потоков на ЦП.
Сравнение
dx11/12 пример 1 - наземка
dx11/12 пример 2 - ВПП
dx11/12 пример 3 - Бенчмарк Танковое сражение (CPU)
Сравнивая изображения, можно видеть заметный прирост FPS (7-11%) в статичных сценах на dx12, при этом, на местах выбитого бетона можно видеть более интенсивное затенение. В бенчмарке прирост по среднему ФПС составил целых 58% и 56% по минимальному. В DX12 минимальный При этом, использование видеобуфера увеличилось на 1-2 Гб.
Второй тест в 16 потоков на ЦП.
Сравнение
dx11/12 пример 1 - наземка
dx11/12 пример 2 - ВПП
dx11/12 пример 3 - Бенчмарк Танковое сражение (CPU)
Видно, что многопоточность, несмотря на нули по загрузке потоков (у меня она всегда странно работает в мониторинге), привнесла 12% для DX11 и 7% для DX12 по минимальному ФПС, привнесла 3,5% среднему ФПС для DX11 и не оказала влияния на средний ФПС для DX12.
В статичных сценах многопоточность увеличила ФПС на 6% в танковой сцене и уменьшила ФПС на 3-4% в сцене на ВПП. В целом, мгновенные значения ФПС не настолько показательны, насколько показательны значения бенчмарка по причине плавающего примерно на 5% от своего значения мгновенного ФПС, хотя Dx12 и видится в этом плане более стабильным.
Также можно заметить освободившуюся видеопамять по неизвестной причине.
По итогу, выбор падает, конечно же, на Dx12, однако, несмотря на более производительную работу до 58%, а так же доступ к RTX-фичам и новым видам сглаживания, в данный момент (версия 2.41.0.21) Dx12 иногда может ронять клиент. Уверен, что падения устранят в ближайших патчах, не оставив ни единственной причины оставаться на Dx11.
Сначала сравним общий план, затем увеличенную часть для самых комфортных методов. Тесты не включают ультрапроизводительные пресеты, потому что они генерируют совсем неиграбельную картинку. Не забывайте поглядывать на мониторинг компьютера.
Напротив названия метода отмечен мгновенный ФПС скриншота и средний ФПС бенчмарка “Танковое сражение”.
Общий план по порядку
Без сглаживания - 387/373 fps
FXAA LQ - 376/368 fps
FXAA HQ - 375/364 fps
TAA - 362/354 fps
DLSS 3.7.20 в нативе - 346/328 fps
DLSS 3.7.20 в качестве - 380/355 fps
XeSS 1.3.0 в нативе - 324/298 fps
XeSS 1.3.0 в качестве - 364/342 fps
FSR 3.1 в нативе - 340/310 fps
FSR 3.1 в качестве - 376/358 fps
TSR в нативе - 369/350 fps
TSR в качестве - 423/378 fps
SSAA 4x - 214/199 fps
SSAA 4x + FSR в балансе - 229/211 fps
И посмотрим на приближенное изображение в двух примерах. Так как нам неизвестно какое начальное разрешение используют предустановки апскейлеров, кропы будем сравнивать только в нативном качестве, кроме комбинации SSAA и FSR, которую включим в “баланс”. Почему?
Разберем здесь.
SSAA вкупе с нативным FSR является САМЫМ чётким и САМЫМ жрущим производительность методом. Бенчмарки “танковое сражение” и “танковое сражение (CPU)” выдали 123 ФПС в среднем и 106 минимального. Это подходит вплотную к той границе в 120 ФПС, которую мы обозначили ранее, а значит, у нас не остаётся производительности для более тяжелых условий, че мв бенчмарке, например, при обстреле нас зениткой с обилием эффектов или при наличии сложных сцен на новых картах. В ангаре, который является сложной сценой, ФПС падает меньше 100, например.
Заметно больше производительности даёт применение TSR, хотя сам метод склонен к мерцанию, поэтому применимость низкая.
В общем, если у вас схожее железо и вам хватит 80-120 ФПС, а так же вы не боитесь шума и температур видеокарты, рекомендую остановиться на SSAA+FSR в нативе. Лучшей картинки на сегодня не добиться.
В тестах будем использовать более щадящий режим SSAA с FSR в балансе, потому что так показатели производительности будут схожими с работой одного лишь SSAA.
Кропнутые скриншоты, ИЛС
Без сглаживания
FXAA HQ
TAA
DLSS 3.7.20 в нативе
XeSS 1.3.0 в нативе
FSR 3.1 в нативе
TSR в нативе
SSAA 4x
SSAA 4x + FSR в балансе
Кропнутые скриншоты, РЛС
Без сглаживания
FXAA HQ
TAA
DLSS 3.7.20 в нативе
XeSS 1.3.0 в нативе
FSR 3.1 в нативе
TSR в нативе
SSAA 4x
SSAA 4x + FSR в балансе (игра вылетела, поэтому ракурс не на 100% совпадает)
Выводы и субъективные оценки:
- Без сглаживания. Всё рябит и мельтешит, зато без мыла и производительно.
Польза 1/10. - SSAA 4x. Ценой потери половины производительности является очень чётким методом, однако из-за этого и сыпется на лесенки. При этом, потребление видеокарты переваливает за 300W, что сказывается на шуме и температуре. Другие методы гораздо спокойнее в плане нагрева. До патча я использовал именно этот метод сглаживания вместе с ТАА, чтобы убирать лесенки, однако теперь можно скомбинировать SSAA с FSR или TSR, и выглядит это очень хорошо. Комбинация с FSR является лучшей с точки зрения чёткости картинки.
Польза 2/10 для SSAA самого по себе, Польза 8/10 для использования вместе с FSR. - FXAA HQ. Метод, доступный всем, однако, сглаживает только границы объектов. Немногим лучше несглаженной картинки, Low Quality версия сыпет лесенками даже на границах объектов.
Польза 3/10 для HQ и Польза 2/10 для LQ.
Методы выше имеют более чёткую отрисовку теней - обратите внимание, например, на тени от деревьев на SSAA, FXAA и на других методах. - ТАА. Временное сглаживание, которое почти не работает в статике, так как использует данные предыдущего кадра для сглаживания. В динамике по этой же причине может оставлять следы от предыдущих кадров в новых, так называемый, гостинг. Рябит и изменяет очертания в динамике.
Польза 2/10. - DLSS. Доступен только для карт nvidia. Хоть общий план и выглядит мыльноватым, алгоритм убирает почти полностью рябь от сеток, решеток и выглядит довольно приятно. Гостинг не заметен. Излишнее мыло можно “вылечить” регулируя ползунок резкости. Пресет “качество” хоть и даёт прирост FPS, наблюдаются рябь и артефакты, например, ближайшая труба пошла волной по краям, когда в нативе она выглядит отлично. Является лучшим для восстановления картинки с сохранением деталей.
Польза 8/10 для нативного и Польза 7/10 для качества. - XeSS. Показывает схожие с DLSS результаты в нативе, хотя и имеет меньше деталей при наихудшей производительности среди всех апскейлеров. Не умеет обрабатывать решётки. Зато доступен более широкому спектру пользователей. Пресет “качество” рябит, пикселит и имеет какое-то заметное горизонтальное размытие. Также показалось, что “качество” оказывает наиболее негативное влияние на переключение ЛОДов и дистанцию появления объектов.
Польза 7/10 для нативного и Польза 3/10 для качества. - FSR. Доступен всем, по сути это чуть более хитрый фильтр резкости. По чёткости результат очень хороший, по производительности чуть уступает DLSS. Степень мыльности на нативном DLSS и “качестве” FSR очень схожа. Гостинг заметен на деревьях. Если снижать качество ниже - растительность превратится в однотонную шумящую кашицу, так как метод имеет тенденцию объединять соседние оттенки в один цвет. Также из-за этого искры могут становиться ярко-красными. Не умеет обрабатывать решётки, как DLSS. Однако, является самым доступным и дешёвым по производительности методом сглаживания с отличным результатом по чёткости.
польза 8/10 для нативного и Польза 6/10 для качества. - TSR. Сильно мерцает даже в нативе. В “качестве” глазам совсем неприятно. Зато очень хорошая производительность.
Польза 6/10 для нативного и Польза 4/10 для качества.
В целом, внимания достойны: DLSS в нативе и качестве - по причине хорошего алгоритма восстановления изображения, FSR в нативе - по причине доступности, хорошей чёткости и производительности, SSAA+FSR в балансе - по причине наилучшей чёткости.
Мне очень нравится, как выглядит размытие движения, выставленное на 2 пункта. Оно прибавляет плавность даже на 165 Hz мониторе, но в такой малой степени явно не выделяется, даёт эффект на уровне ощущений. Особенно хорошо выглядит при пробеге по ВПП.
Однако, использовать его я не могу ввиду нескольких обидных визуальных артефактов на кустах и обломках, которые нет способа устранить, кроме как выключив размытие.Проверено, что дело не в методах сглаживания, проблема воспроизводится и без сглаживания вовсе и даже с SSAA 4Х.
UPD. В патче 2.41.0.51 артефакты размытия обломков авиации исправили, однако, горящие части самолетов всё ещё артефачат. Картинки обновил на актуальные. Следим за ситуацией дальше.
Нет.
Но давайте протестим.
Возьмём для сравнения DLSS в нативе, как комфортный и рабочий метод сглаживания, к тому же мы знаем, что с ним ФПС избыточен (346 ФПС в бенчмарке). Нам надо стремиться нагрузить видеокарту так, чтобы ФПС держался в диапазоне 150-200. Посмотрим на сцены без RTX и с ним для визуальной оценки картинки. Для оценки производительности в углу есть мониторинг и мгновенный ФПС. Также напротив каждого названия сцены оставлю средний/минимальный ФПС в бенчмарке “танковое сражение”. Сразу грубанём ультравысокий пресет.
Видим тени на далеких объектах на земле типа деревьев и теплиц и более контрастное и рассеянное затенение на утёнке. В обмен на 59% производительности. Пока соблюдаем диапазон 150-200 ФПС.
Картинка становится контрастной, отражения выглядят прикольно, затенение более правдивое. Но строится изображение очень долго. Стоп-кадр постепенно достраивается в течение секунд десяти. К тому же мы потеряли 72% производительности и опустились сильно за отмеченную границу. Хорошо, давайте изменим пресет трассировки на средний, посмотрим, как будут обстоять дела.
Видно, что на заборе затенение пошло в шахматном порядке, дерево перестало отдавать свой цвет окружению, отражения снизили разрешение, однако, мы обратно заехали в диапазон 150-200 ФПС и потеряли всего-то 49% производительности. Тестим дальше, используя средний пресет.
Хоть и вновь производительность упала ниже оговоренного уровня, изображение получило серьезный буст по затенению. Обратите внимание на тени на корпусе, на затенение веток деревьев самими собой, на рассеянные тени пальм. Отражения в стёклах зданий также придают картинке глубину. При классическом рендере здания выглядят совершенно вырвиглазно.
Давайте попробуем эту же сцену в низком РТХ, чтобы обеспечить приемлемый фреймрейт.
По сути, средний отличается только дистанцией охвата RТ и присутствием теней в отражениях. Поэтому, прирост незначительный, мы всё ещё не находимся в нужном нам диапазоне.
Не достигнем мы его даже если уберем рассеивание глобального освещения с трассировкой (RTAO), хотя в картинке потеряем значительно:
Причём, отсутствие RTAO снижает производительность. Он оказывается и полезен и красив. Давайте вернем RTAO обратно, уберем отрисовку теней трассировкой (RTSM):
Мы вернулись в диапазон 150-200 в мгновенном ФПС, однако в бенчмарке наблюдалось снижение производительности при снижении качества графики. Нонсенс. К тому же потеряли рассеянные тени. Ну и ладно. Давайте посмотрим, что даст для производительности отключение отражений (RTR) совсем.
Выиграли ещё немного кадров, однако картинка в данной сцене стала совсем скучной без зеркальной поверхности зданий. Может быть, мы тогда сможем использовать только лишь одни RT отражения без других методов на самом минимальном качестве?
Может быть. Мы всё ещё в краю диапазона 150-200 в этой конкретной сцене. Однако, данные бенчмарка по среднему ФПС не отличаются на любой из низких настроек и составляют 138 кадров. Увеличивается только минимальный ФПС.
Вероятно, причина снижения ФПС вместе со снижением качества RT заключается в перекладывании процессов на узкое горлышко системы, например, вместо свободных RT ядер начинают работать растровые блоки, которые уже заняты методами построения картинки, а на них сваливают ещё дополнительную работу, которую могли бы выполнять RT-ядра.
В целом, в боях ситуация может быть очень разной и ни один RT метод не окажется неощутимым для FPS. RT сильно зависит от условий сцены, некоторые карты при некоторых погодных условиях сажают 4080 в лужу, показывая 60-80 кадров, другие локации могут обеспечить 140 кадров. Всё очень нестабильно, из-за этого непременимо в обычный боях. При этом тени шумят и иногда совсем уж сильно затемняют городские улицы. И всё сопровождается фризами время от времени. Оно того не стоит. Лучше потратить эту производительность на хорошее сглаживание.
Есть выбор - использовать среду выполнения Oculus или Steam VR.
Сразу скажу, что рендера в нативном разрешении шлема (4128х2208) не хватает для комфортного восприятия окружения игры, поэтому с ходу делаем множитель разрешения 1,3х, получая 5408х2912, что является максимальным разрешением для Oculus в тундре. В Steam VR мы можем выбирать разрешение ещё выше, однако у Steam VR существует какое-то своё понимание соотношений сторон, поэтому разрешение немного отличается от выставленного в окулус и составляет 5384х2944. Разница в в площади пикселей получается около ста тысяч: 15 748 096 в Oculus против 15 850 496 в Steam VR. Погрешность меньше процента.
Смотрим производительность Dx11 в Oculus и Steam VR, затем в Dx12 также в двух средах, используем бенчмарк “Восточный фронт”. Без сглаживания. Режим стримера VR, дающий более широкое поле зрения на монитор, включен. Первое значение - средний ФПС, второе - минимальный ФПС.
Настройки Oculus Debug Tools
Обязательно отключен ASW, чтобы не резал FPS пополам. Шлем залочен на 90 Hz.
Dx11 и Oculus - 87,8 /68,6;
Dx11 и Steam VR - 88,9/73,2;
Dx12 и Oculus - 89,6/83,2;
Dx12 и Steam VR - 89.3/83,3.
Отдельно отмечу заметную и большую проблему с откатом кадра назад с любыми настройками, с любым средством исполнения и любой средой выполнения. Мне не удаётся избежать их вообще никаким способом. Иногда мне кажется, что это проблема стриминга в шлем, но потом я вижу, что эти дергания остаются на записи:
и вот как они выглядят.
Обратите внимание на дёргания Су-39 в конце
https://www.youtube.com/shorts/Y1msjwi3UaI
Вот графики кадров для SteamVR
В правом верхнем углу оранжевые палочки обозначают пропуски кадров. Пропуск происходит по CPU, после чего дублируется в GPU. И также фреймрейт показывает афтербернер в левом верхнем углу, там тоже видно скачки, означающие, что кадр задержался дольше, чем ему положено.
Вот я решил полностью убить графику в 0, кроме теней, и уронить разрешение - но пропуски кадров сохраняются.
Вот графики кадров для Oculus
Здесь фреймрейт более ровный, он и ощущается более ровным, но откаты кадров всё равно наблюдаются, по крайней мере, внутри шлема их отчётливо видно.
Если у вас есть предположение, или вы наверняка знаете в чём дело, пожалуйста, напишите. А пока что я попытаюсь у себя погнать оперативку и понизить тайминги.
Dx12 и в VR обошёл Dx11, это видно и по минимальному FPS и по среднему, статистику которого портят подфризывания и кратковременные просадки, которые чаще происходят в Dx11. Определились, Dx12 годится и как API для монитора, так и для VR. При этом, мы увидели, что в бенчмарке в Dx12 обе среды выполнения показали себя одинаково, а значит строим предпочтения, исходя из достоинств и недостатков.
Oculus достоинства:
- Тундра только в нём умеет понимать, когда шлем снят, и переключается в плоский режим и обратно, когда шлем надет;
- Меньше лишних прослоек между ПК и игрой.
Oculus недостатки:
- не умеет поднимать разрешение выше 5408х2912.
Steam достоинства:
- Больше настроек изображения;
- Оверлеи, на которые можно выводить мониторинг и чаты;
- Уведомления Steam всегда на виду.
Steam недостатки:
- Допускает фризы с большей частотой, что видно по графикам кадра и субъективным ощущениям, хотя в бенчмарке это не подтвердилось;
- Дольше запускать игру.
Для дальнейших тестов, которые предполагают увеличение разрешения рендера, подходит только SteamVR.
На скриншотах тяжело передать ощущения от того, что видно в шлеме, поэтому дальнейшие тесты стоит воспринимать в большей мере через текст, нежели чем через скриншоты, которые я всё-таки постараюсь сделать поддающимися сравнению. FSR не поддерживается в VR (как и RT технологии кстати), множителем SSAA мы управляем сами через программы окулуса и стима. В тесте не участвуют FXAA LQ, потому что от него почти нет эффекта; ТАА, потому что неприятно размывает, при этом мерцание сеток и деревьев остаётся; и TSR; потому что наименее производителен. Выберем множители 1,3х (5384х2944) и 1,5х (6664х3644).
Напротив каждого варианта также оставляю данные бенчмарка “Восточный фронт”.
Картинки
SSAA 1,3х - 89,5/84,2
SSAA 1,3х + FXAA HQ - 89,4/82,9
SSAA 1,3х + DLSS натив - 88,1/74,2
SSAA 1,5х - 87,3/78,7
SSAA 1,5х + FXAA HQ - 85,3/73,8
SSAA 1,5х + DLSS натив - 64,8/46,8
В 1,3х видно, что DLSS размыливает ИЛС, вероятно, алгоритм путается из-за ореолов. FXAA Выглядит неплохо, к тому же с ним наименьшее количество пропавших кадров и загрузка GPU, при этом он немного сглаживает лесенки, видимые при простом SSAA.
Однако, DLSS гораздо лучше справляется с отрисовкой растительности и сеток, в этом ему нет равных, хоть и график кадра в бенчмарке у него просто ужасный.
В 1,5х разрешении DLSS уничтожил производительность, в графике не осталось ни одного кадра, который срендерился бы вовремя для 90 Hz. Но выглядит лучше всех остальных. FXAA HQ также не держит нужное количество кадров, как и просто SSAA, к тому же, всё ещё сыпет лесенками на растительности и сетках.
Похоже, для связки 5800x и RTX 4080 имеет смысл держать множитель SSAA в районе 1,20х для режима 72 Hz, причём, без применения никаких других типов сглаживания, кроме FXAA HQ, в пользу производительности.
Если же использовать VR, играя на наземной технике, то применять следует только DLSS, потому что только он побеждает мельтешение кустов и сеток.
На этом, пожалуй, всё. Надеюсь, это “исследование” поможет определиться с графикой в тундре не только мне. Пишите, если где накосячил.
