Облачные игры: стресс-тест 5 облачных игровых сервисов плохим интернетом
Около года назад я публиковала статью «Облачные игры: оценка возможностей сервисов для игры на слабых ПК из первых рук». В ней анализировались плюсы и минусы разных сервисов для облачных игр на слабых ПК. Я в ходе игры тестировала каждый сервис и поделилась в итоге общим впечатлением.
В комментариях к той и другим похожим статьям читатели часто делились впечатлениями о разных игровых сервисах. Нередко встречались противоположные мнения об одном и том же. У кого-то все идеально, а кто-то играть не может из-за лагов и фризов. Тогда у меня возникла идея оценить качество работы этих сервисов в разных условиях — от идеальных до ужасных. Речь идет о качестве сетей, ведь далеко не всегда пользователь может похвастаться быстрым и беспроблемным каналом связи, верно? В общем, под катом — оценка сервисов с симуляцией разного качества работы сети.
В чем вообще проблема?
Как и говорилось выше — в качестве связи. А точнее — в потере пакетов в ходе игры. Чем выше потери, тем больше проблем у геймера, тем меньше он доволен игрой. А ведь редко у кого есть идеальный канал связи вроде оптоволокна до устройства, причем с выделенным, а не пошаренным на всех обитателей многоквартирного дома интернетом.
Для справки — при скорости соединения в 25 Мбит/с для передачи 1 фрейма/кадра нужно 40-50 пакетов данных. Чем больше пакетов теряется, тем менее качественной становится картинка, и тем сильнее заметны лаги и фризы. В особо тяжелых случаях играть становится просто невозможно.
Естественно, сам облачный сервис никак не может повлиять на ширину и стабильность канала пользователя (хотя было бы отлично, конечно). Но зато можно предусмотреть разные способы нивелирования проблем связи. Какие сервисы справляются с проблемой лучше всех — увидим ниже.
Что именно сравниваем?
Обычный ПК (Intel i3-8100, GTX 1060 6 GB, 8GB RAM), GeForce Now (его русскую версию GFN с серверами в Москве), Loudplay, Vortex, Playkey, Stadia. На всех сервисах, кроме Stadia, изучаем качество игры в «Ведьмака». У Google Stadia на момент написания статьи этой игры не было, поэтому пришлось тестировать другую — «Одиссею».
Какие условия и методика тестирования?
Тестируем из Москвы. Провайдер — МГТС, тариф 500 Мбит/с, подключение кабельное, не WiFi. Настройки качества графики в сервисах берем по умолчанию, разрешение — FullHD.
При помощи программы Clumsy моделируем проблемы с сетью, а именно, потери пакетов разного вида и объема.
Равномерные одиночные потери. Это когда теряется всего 1 пакет и потери распределены более-менее равномерно. Так, равномерные потери 10% означают, что на 100 пакетов каждый 10-й теряется, но всегда только 1 пакет. Проблема обычно проявляется при искажениях (экранировании) на канале от клиента до сервера.
Тестируем равномерные потери 5%, 10%, 25%.
Неравномерные массовые потери, когда в какой-то один момент сразу теряется 40-70 пакетов подряд. Такие потери чаще всего возникают при проблемах с сетевым оборудованием (роутерами и т.п.) у пользователя или у провайдера. Могут быть связаны с переполнением буфера сетевого оборудования на линии связи «пользователь — сервер». WiFi с толстыми стенами тоже может вызывать такие потери. Загруженность беспроводной сети из-за наличия большого количества устройств — еще одна причина, очень характерная для офисов и многоквартирных домов.
Тестируем неравномерные потери 0,01%, 0,1%, 0,5%.
Ниже я анализирую все эти кейсы и прикладываю видеосравнение для наглядности. А в конце статьи даю ссылку на сырые, немонтированные видео геймплея из всех сервисов и кейсов — там можно детальнее рассмотреть артефакты, а также техническую информацию (во всех сервисах, кроме Stadia, записаны данные технической консоли; у Stadia таких не нашла).
Поехали!
Ниже — 7 сценариев стресс-теста и видео с таймстампами (видео одно и то же, для удобства в каждом пункте просмотр начинается с нужного момента). В самом конце поста — исходные ролики для каждого из сервисов. Видео мне помог сделать хороший знакомый, за что ему спасибо!
Сценарий №1. Идеальные условия. Нулевые потери в сети
Все, как и должно быть в идеальном мире. Проблем со связью нет, разрывов — ни одного, помех нет, ваша точка доступа — светоч интернета. В таких тепличных условиях почти все участники тестирования показывают себя достойно.
В каждый сценарий мы взяли кадры из игры на ПК как эталон. Понятно, что на него качество сети никак не влияет, игра запускается на ПК локально. Наличие этих кадров отвечает на вопрос “а чувствуется ли разница при игре в облаке по сравнению с игрой на своем ПК”. В идеальных условиях в нашем случае — не чувствуется у большинства сервисов. Ниже про ПК уже ничего писать не будем, просто запомните, что он есть.
Все хорошо, картинка четкая, процесс идет гладко, без фризов.
Вот Vortex портит наш идеальный мир. У него сразу же начались проблемы — картинка похуже, чем все остальные, плюс хорошо заметны «тормоза». Возможная проблема — игровые сервера расположены далеко от Москвы плюс железо на игровых серверах, похоже, слабее и FullHD вывозит плохо. Во всех тестах Vortex показал себя плохо. Если у кого-то есть положительный опыт игры с Vortex — пишите в комментариях, поделитесь, из какого места играли и насколько хорошо все сложилось.
Все отлично, прямо как на локальном ПК. Видимых проблем вроде фризов, лагов и т.п. нет.
Сервис демонстрирует отличную картинку, видимых проблем нет.
Игровой сервис от Google работает отлично несмотря на то, что серверов в РФ у него нет, да и вообще официально Stadia не работает в России. Тем не менее, все хорошо. Жаль, конечно, что «Ведьмака» у Stadia не было на момент игры, но что поделать, взяли “Одиссею” —тоже требовательная, тоже про мужика, который рубит людей и животных.
Сценарий №2. Равномерные потери 5%
В этом тесте из 100 пакетов теряется примерно каждый 20-й. Напомню, что для отрисовки одного кадра нужно 40-50 пакетов.
У сервиса от Nvidia все хорошо, проблем нет. Картинка несколько более замылена, чем у Playkey, но «Ведьмак» по-прежнему играбелен.
Здесь все стало еще хуже. Почему — не совсем непонятно, скорее всего, не предусмотрена избыточность или она минимальна. Избыточность — это помехоустойчивое кодирование пересылаемых данных (FEC — Forward Error Correction). Эта технология восстанавливает данные при частичной потере из-за проблем в сети. Реализовать и настроить ее можно по-разному, и, судя по результатам, создатели Vortex в этом не преуспели. Даже с мизерными равномерными потерями играть не получится. В ходе последующих тестов Vortex просто «умер».
Все хорошо, особой разницы с идеальными условиями нет. Возможно, помогает то, что сервера компании расположены в том числе и в Москве, откуда проводились испытания. Ну и, возможно, лучше настроена вышеупомянутая избыточность.
Сервис резко стал неиграбельным, несмотря на относительно малые потери пакетов. В чем может быть дело? Предположу, что Loudplay работает с TCP-протоколом. В этом случае, пока нет подтверждения получения пакета, другие пакеты не отправляются, система ожидает подтверждения о доставке. Соответственно, если пакет потерялся, подтверждения о его доставке не будет, новые пакеты не отправятся, картинка встанет колом, конец истории.
А вот если использовать UDP, то подтверждение на получение пакета не понадобится. Насколько можно судить, все прочие сервисы, кроме Loudplay, используют UDP-протокол. Если это не так, поправьте меня, пожалуйста, в комментариях.
Все играбельно. Иногда пикселизируется картинка, есть минимальные задержки отклика. Возможно, неидеально отрабатывает помехоустойчивое кодирование, отсюда незначительные артефакты при играбельном в целом потоке.
Сценарий №3. Равномерные потери 10%
Теряем каждый 10-й пакет на сотню. Это уже вызов для сервисов. Чтобы эффективно справляться с такими потерями, нужны технологи по восстановлению и/или повторной отправке потерянных данных.
У Geforce наблюдаются небольшие просадки в качестве видеопотока. Насколько можно судить, GFN реагирует на проблемы в сети, стараясь их уменьшить. Сервис уменьшает битрейт, то есть количество бит для передачи данных. Так он пытается снизить нагрузку на недостаточно качественную, по его мнению, сеть и сохранить стабильное соединение. И к стабильности вопросов действительно нет, но вот качество видео страдает ощутимо. Видим значительную пикселизацию картинки. Ну а поскольку моделирование предполагает постоянную потерю 10% пакетов, то снижение битрейта не особо помогает, ситуация в норму не приходит.
В реальной жизни картинка, скорее всего, будет не стабильно плохой, а плавающей. Увеличились потери — изображение размылилось; потери сократились — изображение вернулось в норму и так далее. Игровому опыту это не на пользу, конечно.
Особых проблем нет. Вероятно, алгоритм детектирует проблемы на сети, определяет уровень потерь и больше упирает на избыточность, а не на снижение битрейта. Получается, при 10% равномерных потерь качество картинки практически не меняется, пользователь такие потери вряд ли заметит.
Неработоспособен, он просто не запустился. В ходе дальнейших тестов ситуация повторилась. Насколько можно судить, этот сервис никак не подстраивается под проблемы с сетью. Возможно, именно TCP-протокол тому виной. Малейшие потери парализуют сервис полностью. Не очень практично для реальной жизни, конечно.
Тоже большие проблемы. Играть в таких условиях нельзя, хотя картинка еще есть и персонаж продолжает бежать, правда, рывками. Думаю, дело все в той же плохо реализованной или отсутствующей избыточности. Пакеты теряются часто и никак не восстанавливаются. В итоге качество изображения деградирует до неиграбельного уровня.
К сожалению, здесь все плохо. Наблюдается разрыв потока, из-за чего события на экране происходят рывками, играть крайне сложно. Можно предположить, что проблема появилась, как и в случае с Vortex, из-за минимальной избыточности или ее отсутствия. Я проконсультировалась с парой знакомых, которые «в теме», они заявили, что Stadia, скорее всего, дожидается полной сборки кадра. В отличие от GFN, она не пытается спасти положение тотальным понижением битрейта. В итоге артефактов нет, но появляются фризы и лаги (у GFN, наоборот, фризов/лагов меньше, но из-за низкого битрейта картинка совсем непривлекательная).
Остальные сервисы тоже, похоже, не дожидаются полной сборки кадра, заменяя пропавшую часть фрагментом старого кадра. Это хорошее решение, в большинстве случаев пользователь не заметит подвоха (в секунду сменяется 30+ кадров), хотя порой могут возникать артефакты.
Сценарий №4. Равномерные потери 25%
Теряется каждый четвертый пакет. Становится все страшнее интереснее. Вообще, при таком “дырявом” соединении нормальная игра в облаке едва ли возможна. Хотя некоторые участники сравнения справляются, пусть не идеально.
Проблемы уже весьма заметные. Картинка пикселизирована и замылена. Играть все еще можно, но это уже совсем не то, что предлагал GFN в самом начале. И точно не то, как нужно играть в красивые игры. Красоту-то уже не оценить.
Игровой процесс идет неплохо. Плавность есть, хотя картинка немного и страдает. Кстати, слева вверху — цифры, сколько восстанавливается потерянных пакетов. Как видим, восстанавливается 96% пакетов.
Играть нельзя даже при очень большом желании, фризы (остановка изображение, возобновление видеопотока с нового фрагмента) еще заметнее.
Сервис практически неиграбелен. Причины уже назывались выше. Ждет сборки кадра, избыточность минимальна, при таких потерях ее не хватает.
Сценарий №5. Неравномерные потери 0,01%.
На 10 000 пакетов 1 раз теряется 40-70 пакетов подряд. То есть теряем примерно 1 из 200 кадров. Бывает, если буфер сетевого устройства переполнен и все новые пакеты просто выбрасываются (дропаются), пока буфер не освободится. Все участники сравнения, кроме Loudplay, такие потери в той или иной степени отработали.
Картинка совсем немного потеряла качество, стала несколько мутноватой, но все вполне играбельно.
Все очень неплохо. Картинка плавная, изображение — хорошее. Играть можно без проблем.
Первые несколько секунд картинка была, герой даже побежал. Но связь с сервером почти сразу же была потеряна. Ох уж этот TCP-протокол. Первая же потеря срубила сервис на корню.
Наблюдаются обычные проблемы. Фризы, лаги и вот это все. Играть было бы ну очень сложно при таких условиях.
Играбельно. Заметны небольшие просадки, картинка иногда пикселизируется.
Сценарий №6. Неравномерные потери 0,1%
На 10 000 пакетов 10 раз теряется 40-70 пакетов подряд. Получается, что теряем 10 из 200 кадров.
Сразу скажу, что заметные проблемы появились у большинства сервисов. Например, дергается картинка, так что избыточность здесь уже не помогает. То есть положительный эффект в случае использования технологии избыточности есть, но он невелик.
Дело в том, что время реакции на действия пользователя и самой игры — ограничено, видеопоток должен быть непрерывным. Восстановить поток до приемлемого качества нельзя несмотря ни на какие усилия сервисов.
Появляются артефакты (попытка компенсировать потерю пакетов, данных не хватает) и рывки изображения.
Качество картинки заметно упало, явно понижен битрейт, причем весьма значительно.
Справляется лучше — вероятно, потому, что хорошо настроена избыточность, плюс алгоритм битрейта считает потери не очень высокими и не превращает картинку в пикселизированную кашу.
Запустился, но с ужасным качеством картинки. Очень заметны рывки и просадки. Играть при таких условиях вряд ли возможно.
Хорошо заметны рывки, это четкий показатель, что избыточности не хватает. Картинка замирает, потом появляются другие кадры, возникает обрыв видеопотока. Играть, в принципе, можно, если есть большое желание и клиническая склонность к самоистязанию.
Сценарий №7. Неравномерные потери 0,5%
На 10 000 пакетов 50 раз теряется 40-70 пакетов подряд. Теряем 50 кадров из 200.
Ситуация класса “форменный пи***ц”. Ваш роутер искрит, у провайдера авария, провода погрызли мыши, но вы все равно хотите играть в облаке. Какой же сервис вам выбрать?
Играть уже очень сложно, если вообще возможно — очень сильно понижен битрейт. Теряются кадры, вместо нормальной картинки мы видим «мыло». Кадры не восстанавливаются — информации для восстановления не хватает. Если у GFN восстановление вообще предусмотрено. То, как агрессивно сервис пытается спасать положение битрейтом, вызывает сомнения в его готовности работать с избыточностью.
Есть искажение кадра, изображение подергивается, то есть повторяются элементы отдельных кадров. Видно, что большая часть “битого” кадра была восстановлена из кусков предыдущего. То есть в новых кадрах есть части старых кадров. Но изображение при этом более-менее четкое. Управлять можно, но в динамичных сценах, например, в драке, где нужна хорошая реакция — сложно.
Запустился, но лучше бы не запускался — играть в это нельзя.
Сервис в таких условиях неиграбелен. Причины — необходимость дожидаться сборки кадра и слабая избыточность.
Кто победитель?
Рейтинг, конечно, субъективный. В комментариях можно поспорить. Ну и первое место, конечно, за локальным ПК. Именно из-за того, что облачные сервисы крайне чувствительны к качеству сети, а качество это довольно нестабильно в реальном мире, собственный игровой ПК остается вне конкуренции. Но если его по каким-то причинам нет, то смотрите рейтинг.
Почему мы решили делать сервис облачного гейминга на видеокартах AMD
Рынок облачного гейминга в России развивается ударными темпами. Здесь у нас и Loudplay, и MY.GAMES Cloud (ех. Playkey), GFN.ru. Мобильные операторы связи тоже находят свою выгоду и заключают партнерские соглашения с перечисленными сервисами, запуская собственные проекты. Так поступила «Вымпелком», запустив Beeline Gaming, а вслед за ней — МТС, Мегафон и Tele2. Особых проблем запуск таких сервисов не доставляет — ведь они реализованы на основе платформ партнеров, которые давно отлажены и работают как нужно.
Год назад мы в Playkey стали частью MY.GAMES, вложив технологию своего облачного сервиса в основу MY.GAMES Cloud. Все это время сервис находится в состоянии soft launch. А недавно объявили о своем партнерстве с AMD, в рамках которого адаптировали протокол передачи видеопотока сервиса и будем тестировать видеокарты AMD Radeon™ RX 6700 XT на своих серверах. В чем профит этого партнерства для конечного пользователя, почему мы остановились именно на AMD, а не NVIDIA с их мощной трассировкой лучей, а также о том, насколько эта технология критична для игр, запускаемых через стриминговые сервисы, разбираемся в статье.
Что такое Radeon RX 6700 XT: характеристики и бенчмарки
Radeon RX 6700 XT — наиболее бюджетное решение новой 6000-й линейки видеокарт AMD, рассчитанное на комфортную игру в разрешении 1440p в случае растеризации и Full HD с трассировкой лучей. Строится видеокарта на базе 7-нм архитектуры RDNA 2 и обладает всеми характерными для нее преимуществами в виде аппаратной трассировки лучей и прочих функций API DirectX 12 Ultimate, нового кэша Infinity Cache, AMD FidelityFX, улучшенного доступа к видеопамяти Smart Access Memory, 12 ГБ памяти в противовес максимальным 10 ГБ у NVIDIA и многого другого.
По данным AMD, в играх без рейтрейсинга Radeon RX 6700 XT обгоняет GeForce RTX 3060 Ti и где-то RTX 3070. Впрочем, в зависимости от поддержки AMD или NVIDIA разработчиков конкретных игр, соотношение сил здесь может быть несколько различным. Тем не менее, результаты тестов подтверждают, что для комфортной игры в 2.5К Radeon RX 6700 XT вполне подходит.
Что же касается игры через облако, благодаря индивидуальной настройке энкодера под оборудование игрока и комплексу механизмов для борьбы с потерями данных, таких как помехоустойчивое кодирование, пользователь практически защищен от потери пакетов, а вместе с ними от лагов, фризов и «мыльной» картинки. А значит, внешний вид игры на локальном ПК и в облаке практически идентичен. Посудите сами: здесь игра в DOOM при максимальных настройках и качественном устойчивом интернет-соединении происходит на Core i3, 4 GB RAM, MSI GeForce GTX 750:
Что подразумевается под «качественным соединением»? Скажем, на нашем сервисе MY.GAMES Cloud рекомендованы следующие параметры скорости:
10 Мбит/сек для запуска игр в 30 FPS, HD (1280х720);
15 Мбит/сек — 30 FPS, Full HD (1920х1080);
20 Мбит/сек — 60 FPS, Full HD (1920х1080);
25 Мбит/сек — 120 FPS, Full HD (1920×1080).
Логично возникает вопрос: главный тренд передовых AAA-проектов — трассировка лучей, о которой все так много говорят, — как она будет ощущаться при игре в облаке в Full HD?
Ответить на него чуть сложнее, потому как у GPU NVIDIA под эту задачу выделены отдельные ядра для real-time вычислений, а технология DLSS только снижает нагрузку от трассировки. Но так ли это существенно на заре 2022 года, когда игр с рейтрейсингом вышло еще не так много, и насколько реально в принципе получить full path-tracing в 4K и 60 FPS даже на локальном ПК — в этом мы разберемся далее.
Трассировка лучей в современных играх — must-have для геймеров?
Вообще говоря, трассировка лучей — явление далеко не новое и само по себе не требующее специализированного оборудования. Но с появлением серии RTX видеокарт от NVIDIA в 2018 году появилась ее аппаратная поддержка, которая дала мощный буст дальнейшему развитию технологии.
Впервые этот алгоритм был описан Артуром Аппелем из IBM в 1968 году. И уже начиная с 1970-ых годов благодаря CG-специалистам из Lucasfilm, CalTech и других компаний трассировка лучей стала стандартом в индустрии кино и компьютерной графики для создания реалистичного освещения в изображениях. Однако до 2018 года почти вся трассировка лучей выполнялась оффлайн — и даже сегодня CGI в кино требует обширных специализированных серверных ферм на CPU. При этом рендериться один такой кадр может минутами, часами и даже днями, если речь идет о какой-то исключительной детализации. Такой роскоши у видеоигр, требующих частого обновления кадра здесь и сейчас, просто нет.
GPU, напротив, могут работать намного быстрее благодаря большему числу вычислительных ядер для более быстрого выполнения сложных задач.
Традиционно они использовали — и используют до сих пор в подавляющем числе случаев — другую технику для отображения трехмерных объектов на двумерном экране посредством представления объектов в виде треугольников — растеризацию. Пусть результаты ее вычислений и их визуализации дают не такую впечатляющую картину, как трассировка лучей, но зато происходит она в разы быстрее.
Первая программная трассировка лучей — вышедшая в 2009 году NVIDIA OptiX — была реализована как раз-таки с ускорением на GPU. В течение следующего десятилетия OptiX демонстрировала неуклонный рост скорости, обеспечиваемый сменой поколений графических процессоров NVIDIA.
Программную трассировку лучей с ускорением на GPU поддержала и Microsoft, в начале 2018 года представив DXR, который обеспечивает полную поддержку программного обеспечения NVIDIA RTX для трассировки лучей через Microsoft DXR API. Одновременно с ними на помощь в задачах рейтрейсинга пришли специальные тензорные ядра RT, позволившие NVIDIA повысить скорость обработки алгоритмов трассировки в 6 раз в случае RTX 2080 про сравнению с предыдущей GTX 1080 Ti. Затем ту же практику переняла и AMD, начав самостоятельную работу над этой технологией.
Наибольшим откровением трассировка лучей стала, пожалуй, с ее релизом в Minecraft и Quake II, где на фоне довольно примитивной графики улучшенная технология освещения возводит общую картинку на совсем другой уровень. Смотрите:
Что же касается более современных тайтлов с фотореалистичной графикой, ответ на вопрос необходимости трассировки лучей является уже не столь однозначным.
Возьмем, к примеру, Shadow of the Tomb Raider. Конечно, с трассировкой лучей тени становятся более естественными. Но если сравнить картинку с включенной трассировкой и ее отсутствием, разница не кажется столь существенной. При этом сравним падение FPS с включенной трассировкой лучей и без нее: 100 до 60 (либо 120 до 70) — почти в два раза:
То же самое в плане детализации можно увидеть на скриншотах со сравнением трассировки лучей в трех режимах и при отключенной совсем. Найдите 10 отличий:
Другой пример — Metro Exodus. Здесь первый скриншот выполнен с включенной трассировкой лучей, второй — снят без нее:
И она же в динамике:
Напоследок, DOOM Eternal. И снова разница между режимами с включенной и выключенной трассировкой лучей если и видна, то далеко не в каждом кадре:
Разница в качестве графики, конечно, есть, однако реализм картинки не сильно страдает от отсутствия трассировки лучей — особенно в динамике, когда игрок больше сосредоточен на геймплее, нежели рассматривании деталей освещения. А учитывая, какой процент от производительности и значений FPS эта технология отъедает даже на самых топовых видеокартах, актуальность ее включения каждый решает сам для себя.
Здесь стоит оговориться: когда мы говорим о трассировке лучей в современных киноблокбастерах, речь идет о так называемой технологии full path tracing — полной трассировки пути. На самом деле в рейтрейсинге есть множество других методов:
Тени с трассировкой лучей (именно так она реализована в Shadow of the Tomb Raider);
Глобальное освещение с помощью трассировки лучей (как в Metro Exodus);
Отражения с помощью трассировки лучей (например, в Wolfenstein Youngblood).
Святой Грааль трассировки лучей — полная трассировка пути, включает все эти методы. Однако стоит помнить, что чем сложнее метод, тем больше затраты на производительность. Даже в случае Minecraft и Quake II с их довольно примитивной графикой. Взглянем, к примеру, на это видео:
Падение FPS более чем в 3 раза до значения 35-40 кадров в секунду — сами понимаете. В таком случае ни о каком 4K лучше не вспоминать вовсе.
Конечно, вместо частоты кадров можно пожертвовать разрешением, и это отчасти решит проблему, но детализация от этого тоже пострадает — отчего, опять-таки, возникает вопрос, а стоит ли оно того, если разницы вы все равно не увидите, если не играть в 4K. Для которого еще необходимо иметь подходящий дорогостоящий монитор.
Но неужели все действительно так плохо в программным рейтрейсингом?
Хотя тензорные ядра дают хороший буст ускорению трассировки лучей на топовых видеокартах, развитие софтового рейтрейсинга на этом не остановилось. Так, в 2019 году на конференции GDC Crytek представила демо Neo Noir, показывающее возможности версии движка CryEngine 5.7, позволяющей теперь производить расчет отражений через трассировку лучей. Вот оно:
Да, программная трассировка лучей использует отражения с более низким разрешением, меньше типов поверхностей поверхностей количество полигонов упомянутых отражений, однако все еще выглядит впечатляюще.
Со слов Crytek, реализация Neon Noir не зависит от аппаратного обеспечения и «будет работать на большинстве современных графических процессоров AMD и NVIDIA, тогда как другие методы трассировки лучей обычно привязаны к решениям на GPU с выделенными ядрами RT». Для программного обеспечения он использует DirectX 11 в качестве API, поэтому теоретически любая современная карта с его поддержкой может использовать Neo Noir.
Посмотрите, как справляется с трассировкой лучей Neon Noir предшественница RX 6700 XT, RX 5700:
Впоследствии Crytek представила бенчмарк Neon Noir. Приведем результаты тестов ресурса WCCFTech на видеокартах предыдущих поколений — ведь если Neon Noir позиционируется как технология, которая отлично справляется с рейтрейсингом даже на старых видеокартах без RT-ядер, интересно посмотреть на бенчмарки именно для них:
Как видно, в разрешении Full HD при максимальных настройках качества графики с задачей справляются действительно все протестированные видеокарты, если принимать за стандарт значение выше 30 FPS. Что же касается 1440p, ситуация ожидаемо хуже, однако по той же планке в 30 FPS проходит даже самая слабая из видеокарт.
Все это к тому, что в теории вам наверняка будет достаточно и софтового рейтрейсинга для зрелищной игры — не обязательно для этого заводить новейшие карты RX и RTX: Neon Noir является действительно хорошей альтернативой аппаратного рейтрейсинга, доступной для более старых и бюджетных моделей видеокарт. И это отличный задел на будущее для новых игровых проектов, как сделать трассировку лучей более доступной для игроков с самым разным железом.
Подводя итоги
Итак, мы рассмотрели множество различных реализаций трассировки лучей на обширном пуле карт обоих конкурирующих производителей — AMD и NVIDIA — и даже затронули вопросы программного рейтрейсинга. И можно прийти к выводу, что в большинстве случаев нет существенной разницы, играешь ли ты на RX 6700 XT, RTX 3070 или даже RTX 2080, если речь идет о клауд-гейминге.
Поэтому RX 6700 XT — оптимальное решение для игр в 1440p в разрезе клауд-гейминга, которое в рамках нашего партнерского соглашения с AMD поможет снизить косты на содержание оборудования. Как следствие, сервис станет доступнее для конечного пользователя: увеличится количества серверов, а вместе с ним — географический охват.
