Как я Cyberpunk в облаке запускал: часть 2

Когда ты начинаешь долгий путь, деревья — это деревья, вода — это вода, а горы — это горы.

После того, как ты пройдёшь некоторое расстояние, деревья больше не деревья, вода — не вода, а горы больше не горы.

Но после того, как ты проделаешь долгий путь, деревья снова становятся деревьями, вода — водой, а горы — снова горами.

Сразу спойлер, что комфортно поиграть получилось, более того, также удалось получить удовольствие от процесса подготовки к игре. Vox humana!

Первая часть посвящена серверной стороне облачного гейминга, вторая — клиентской.

Эта статья состоит из трёх разделов: характеристики сервера, настройка GPU и сравнительный обзор тонких клиентов.

Дисклеймер

Несмотря на то что с выхода первой части в январе '21 и написания заготовки этой статьи в конце февраля/начале марта '21 прошло больше двух лет, с точки зрения технологий изменилось не так много...

Оставшиеся вопросы из первой части помечены так

I. Характеристики сервера

Кратко опишу стек на серверной стороне: Bare metal server with GPU (RTX A6000), ESXi (7.0U3d) with NVIDIA Host Driver, vCenter (7.0.3), Windows 10 (21H2 19044) with NVIDIA Guest Driver, NVIDIA License Server (2022.02).

В первой части использовался сервер от IBM Cloud, в этой части используется сервер от Фонда Интеллект, за что выражаю благодарность Фонду :)

Как повлияет на уровень сервиса перенос из Dallas(~170ms) во Frankfurt(~30ms)?

В начале '21 IBM Cloud повысил грант с 1 до 10к в месяц, поэтому был взят bare metal c GPU (V100) и низкой задержкой — в результате пинг вместо 150 мс стал 40 мс.

Затем, уже в '22, благодаря тому что сервер Фонда установлен в Москве, задержка снизилась до 5 мс!

Стало возможно комфортно играть, немного забегая вперёд, похоже, что пинг это ключевая компонента качества сервиса облачного гейминга.

Как всё-таки запустить Cyberpunk непосредственно на bare metal?
Неужели нужно поставить grid драйвер?

В заготовке этой статьи из 21' было сказано, что запустить Cyberpunk получилось на ESXi 6.7 с grid драйвером 452.77. Также был вопрос, запустится ли Cyberpunk на tesla драйвере.

Из раздела III. станет понятно, что нужен именно grid драйвер, потому что bare metal это аналог passthrough, а для FullHD разрешения дисплея подходит только grid драйвер. Что касается tesla драйвера, то с ним также должно запуститься, но только с разрешением дисплея 1366x768. Как также станет понятно из раздела III, это связано с лицензией.

II. Настройка GPU

Для настройки GPU важны четыре компонента:

1. Драйвер на ESXi

2. Аппаратные настройки GPU

3. Драйвер гостевой ВМ

4. Сервер лицензий

1. VMware Host Driver

Если после установки ESXi nvidia-smi не работает из коробки, нужно поставить vib из архива с драйвером для vGPU. У меня установлен NVIDIA-VMware_ESXi_7.0_Host_Driver 460.32.04.

2. Firmware GPU settings

Перед установкой драйвера GPU на гостевой ВМ необходимо проверить несколько аппаратных настроек GPU.

Для первых grid (vGPU) M6, M60 использовался gpumodeswitch, позволяющий переключаться между graphics mode и compute mode. Ему на смену (для A40, RTX A5000, RTX A5500, RTX A6000) пришёл displaymodeselector, который настраивает physical_display.

Важно отметить, что для работы displaymodeselector не требуется наличие гостевого драйвера GPU. Но для проверки наличия VGX дисплея гостевой драйвер GPU требуется.

Важны следующие аппаратные настройки GPU:

1. Способ подключения GPU к ВМ: PassThrough или vGPU — способ подключения определяется в ESXi
   
   Для переключения способа подключения GPU необходима перезагрузка сервера, поэтому я считаю эту настройку аппаратной.

2. GPU Driver Mode: graphics (WDDM) или compute (TCC) — для наличия VGX нужен режим graphics
   
   Переключение режима осуществляется командой nvidia-smi.exe -fdm 0 или 1.

3. Display Mode: Enabled или Disabled — эта настройка отвечает за наличие виртуального дисплея (VGX)
   
   Display Mode Enabled означает что в displaymodeselector выбран disabled physical_display type.

Ниже приведена таблица, связывающая аппаратные настройки GPU с возможностью доступа к VGX дисплею — к этому дисплею подключаются тонкие клиенты, не использующие свой дисплей. VGX дисплей устанавливается вместе с гостевым GPU драйвером.

Для тестирования использовались: RDP (у него свой дисплей), Parsec (для проверки VGX available) и ESXi SVGA (дисплей для того чтобы видеть BSOD).

Методика тестирования такова: через диспетчер устройств удаляется драйвер GPU; с помощью displaymodeselector выставляются настройки display type (II) и ВМ перезагружается; затем для установки VGX дисплея ставится GPU драйвер Data Center Driver (см. ниже почему именно он), после чего через nvidia-smi выставляется Driver Mode (III) и затем ВМ снова перезагружается; если OS Boot Ok (IV), то проверяется VGX available (V).

Важно отметить, что для PassThrough после применения displaymodeselector и до установки гостевого драйвера во всех шести случаях первая перезагрузка ВМ проходит успешно, поэтому эта перезагрузка не выносится в отдельный столбец. Также стоит добавить, что если не ставить гостевой драйвер, VGX available будет No, поэтому гостевой драйвер нужен.

Комментарии к цифрам в круглых скобках

(2) PassThrough WDDM physical_display enabled — происходит BSOD, OS Reset

BSOD: Video memory management internal 0xc0000225 (https://learn.microsoft.com/ru-ru/windows-hardware/drivers/debugger/bug-check-0x10e---video-memory-management-internal)

OS Reset: Во время установки гостевого драйвера происходит сброс ОС

BSOD, OS Reset происходит для всех трёх типов гостевых драйверов (о типах гостевых драйверов см. ниже) — видимо действительно нужен физический дисплей :)

(4) PassThrough TCC physical_display enabled — происходит feature из документации displaymodeselector

When a GPU PCle board has physical display ports enabled and the Windows GPU driver mode is set to TCC mode, a picture may appear from the physical display port. However, it is not a GPU accelerated graphics display and there is no NVIDIA graphics driver associated with it. For the physical display port to output a GPU-accelerated NVIDIA display, the Windows GPU driver needs to be running in WDDM mode.

(3) PassThrough TCC physical_display disabled — VGX дисплей есть, но недоступен

Недоступность VGX дисплея для этой конфигурации показывает, что нужен режим WDDM.

(1) PassThrough WDDM physical_display disabled — VGX дисплей есть и доступен

VGX дисплей есть, более того, если подключиться к нему напрямую через, например, Parsec и сделать скриншот, то будет видно два дисплея — второй это ESXi SVGA дисплей.

Вопрос выбора типа гостевого драйвера для этой конфигурации и определения максимального разрешения VGX дисплея, которое как выясняется зависит от выбранного типа гостевого драйвера, рассмотрен ниже.

(5) vGPU WDDM — VGX дисплей есть и доступен

Несмотря на то, что displaymodeselector выдал ошибку Отказано в доступе, а из всех типов гостевых драйверов установился только grid driver, после его установки в Windows стала доступна nvidia-smi, из которой следует, что этой конфигурации vGPU соответствует настройка displaymodeselector physical_display disabled, поскольку в nvidia-smi -q Display Mode Enabled.

ESXi SVGA дисплей на скриншоте, сделанном через Parsec, есть — т.е. также видно два дисплея.

(6) vGPU TCC — VGX дисплей есть, но недоступен

Наличие nvidia-smi в Windows после установки grid драйвера позволило перейти в режим TCC. displaymodeselector также выдал ошибку Отказано в доступе, однако из nvidia-smi -q следует, что этой конфигурации vGPU также соответствует настройка displaymodeselector physical_display disabled, поскольку в nvidia-smi -q Display Mode Enabled.

Стоит отметить, что для этой конфигурации из всех типов гостевых драйверов установился также только grid драйвер.

Итого: VGX дисплей доступен только для WDDM с physical_display disabled.

При составлении представленной выше таблицы для проверки VGX available использовался Data Center Driver. Как показано на рисунке ниже, только он поддерживает оба варианта physical_display type. Однако только этот драйвер использовался только для проверки PassThrough TCC конфигураций (3) и (4), в других же случаях в итоге проверялись все три драйвера.

Также стоит отметить, что для определения и изменения GPU Driver Mode нужна nvidia-smi, которая должна ставиться в Windows вместе с гостевым драйвером. Однако для PassThrough подключения она почему-то не ставится вместе с grid драйвером в конфигурации (1). Таким образом, способ подключения вместе с типом гостевого драйвера влияют на наличие nvidia-smi, которая в свою очередь влияет на возможность определения и изменения GPU Driver Mode.

3. GPU Guest Driver

Как показано на рисунке выше, есть три разных типа драйвера, которые возможно установить на гостевой машине. Я использовал следующие версии этих драйверов:

• 461.33_grid_win10_server2016_server2019_64bit_international

• 526.67-quadro-rtx-desktop-notebook-win10-win11-64bit-international-dch-whql

• 528.33-data-center-tesla-desktop-win10-win11-64bit-dch-international

Start suddenly WSL reference

Поскольку в Windows для Docker'а рекомендуется в качестве бэкенда WSL (2.0), то было бы здорово иметь также возможность работать с (v)GPU и в контейнере.

Для включения nested virtualization нужно чтобы в .vmx конфиге ВМ было vhv.enable="TRUE". Из веб-интерфейса совместить nested virtualization с наличием PCI device не получится, поэтому нужно сделать unregister ВМ в клиенте ESXi, потом через терминал поправить .vmx конфиг ВМ и затем сделать register ВМ в клиенте ESXi.

Ниже приведена таблица, связывающая тип гостевого драйвера с максимальным разрешением VGX дисплея и результатом запуска nvidia-smi в Windows и в WSL. Для тестирования также как и для первой таблицы использовались RDP, Parsec и ESXi SVGA.

Методика тестирования такова: через диспетчер устройств удаляется GPU вместе с гостевым драйвером; затем ставится гостевой драйвер GPU (II) и ВМ перезагружается; если OS Boot Ok (III), то через nvidia control panel определяется VGX Display status (IV) и затем проверяется результат запуска nvidia-smi в Windows и в WSL.

Важно отметить, что nvidia control panel, как и VGX дисплей и nvidia-smi в Windows, ставится вместе с гостевым драйвером. Вид nvidia control panel зависит как от используемого тонкого клиента (для Parsec и RDP панель выглядит по-разному, например, в Parsec есть настройки VGX дисплея), так и от выбранного типа гостевого драйвера GPU (только в grid драйвере есть панель Управление лицензией). Таким образом, более 'широкая' nvidia control panel доступна при подключении к VGX дисплею, установленному с помощью grid драйвера.

Также стоит отметить, что во всех трёх случаях, когда гостевой драйвер GPU установился и перезагрузка ВМ прошла успешно, загрузка WSL также прошла успешно, поэтому эта загрузка не выносится в отдельный столбец.

Комментарии к цифрам в круглых скобках

(1) PassThrough No driver и vGPU No driver — запуск nvidia-smi и в Windows, и в WSL приводит к ошибке

Запуск в Windows приводит к ошибке: "nvidia-smi" не является внутренней или внешней командой, исполняемой программой или пакетным файлом.

Запуск в WSL приводит к ошибке: nvidia-smi NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

Важно отметить, что nvidia-smi в WSL доступна даже когда в Windows удалён GPU драйвер. Однако поскольку GPU драйвер в WSL и Windows единый, то запуск nvidia-smi в WSL приводит к закономерной ошибке, поскольку GPU драйвера нет.

Также стоит сказать, что поскольку гостевой драйвер не установлен, VGX дисплей и nvidia control panel отсутствуют.

(2) vGPU GRID — установка grid драйвера при включённой nested virtualization приводит к BSOD: PAGE FAULT IN NONPAGED AREA

Важно отметить, что когда nested virtualization выключена, OS Boot после установки grid драйвера проходит успешно и максимальное наблюдаемое разрешение VGX дисплея составляет 3840x2160.

Также стоит сказать, что без nested virtualization nvidia-smi в Windows работает, как показано на рисунке ниже. Дополнительная проверка в Windows: torch.cuda.is_available() выдаёт True.

(4) PassThrough GRID — запуск nvidia-smi и в WSL, и в Windows выдаёт тоже самое, что и в (1)

Однако возможно причина ошибки иная, поскольку сам гостевой GPU драйвер установился и WSL запускается, поэтому я провёл дополнительные проверки.

Приложение CUDA samples DeviceQuery в WSL выдаёт:
cudaGetDeviceCount returned 35 -> CUDA driver version is insufficient for CUDA runtime version Result = FAIL

В WSL torch.cuda.is_available() выдаёт False. Однако в Windows torch.cuda.is_available() выдаёт True.

(5) PassThrough Data Center Tesla и Quadro RTX — nvidia-smi и в Windows, и в WSL работает

Однако к сожалению максимальное наблюдаемое разрешение VGX дисплея составляет 1366x768 — почему это так, станет ясно из следующего раздела, посвящённого лицензиям.

Кроме того странно, что Os Boot Ok для Quadro RTX, поскольку этот драйвер не поддерживает physical_display disabled (см. выше рисунок из документации).

Итого: WSL и vGPU несовместимы, WSL работает только с GPU Passthrough.

Если точнее, то дело не в том что WSL несовместим с vGPU, а в том что nested virtualization, необходимая для WSL, несовместима с GRID драйвером, который единственный работает с vGPU — как следует из (2).

В тоже время только GRID драйвер позволяет настроить VGX дисплей с Full HD разрешением, поэтому сделать WSL с Full HD VGX не получится — как следует из (5) и (4).

End Suddenly WSL reference

Итого: для настройки Full HD VGX дисплея подойдут только конфигурации PassThrough WDDM physical_display disabled с GRID драйвером и vGPU WDDM без nested virtualization с GRID драйвером.

Получится ли настроить Passthrough GPU на ESXi?

Да, нужно поменять Active type в vCenter, чтобы изменить GPU conn type с vGPU на PassThrough. Также нужно поставить GRID драйвер, иначе разрешение VGX дисплея будет максимум 1366x768.

4. NVIDIA License Server

В результате анализа типов драйверов осталось не ясно, как именно максимальное разрешение VGX дисплея связано с типом гостевого драйвера — дело в связи типа драйвера с видами лицензии. Таким образом, максимальное разрешение VGX дисплея связано с видом лицензии через тип гостевого драйвера.

Ниже приведена таблица, связывающая вид лицензии с максимальным разрешением VGX дисплея, в зависимости от типа гостевого драйвера. Для тестирования использовался только Parsec, поскольку он подключается к VGX дисплею и поэтому предоставляет доступ к более полной nvidia control panel по сравнению с RDP, который подключается к своему дисплею.

Методика тестирования такова: через диспетчер устройств удаляется GPU вместе с гостевым драйвером; затем ставится гостевой драйвер GPU (II) и ВМ перезагружается; после чего через nvidia control panel проверяется VGX Display status (III) и вид лицензии (IV).

Важно отметить, что хотя существуют версии гостевых драйверов для Linux, это не сценарий облачного гейминга, поэтому во всех случаях используется Windows и OS не выносится в отдельный столбец. Также в таблице не представлен вид лицензии vCS, поскольку этот вид лицензии также не предназначен для облачного гейминга (как следует из документации).

Кроме того, не рассматривается вид лицензии vPC, поскольку он отсутствует в пробной лицензии (о ней см. ниже). Наконец, в nvidia control panel вкладка с лицензией доступна только при установке GRID драйвера, поэтому предполагается, что для остальных типов драйверов используется vApps лицензия (см. подробности в комментариях к таблице ниже).

Также стоит добавить, что несмотря на то что VGX Max Res зависит от архитектуры GPU, VGX Display status приводится для архитектуры RXT A6000 (Ampere).

Комментарии к цифрам в круглых скобках

(1) Passthrough GRID vApps — наблюдаемое максимальное разрешение VGX дисплея при подключении через Parsec составляет 1366x768

Для этого типа драйвера в nvidia control panel присутствует вкладка Управление лицензией, в которой есть возможность переключения между vApps и vWS лицензиями (как показано на рисунке ниже).

Однако как следует из документации: In GPU pass-through mode on Windows, or in a bare-metal deployment on Windows or Linux, a physical GPU requires a vWS license.

(3) Passthrough Quadro RTX и Data Center Tesla — аналогично (1)

Для этих типов драйверов в nvidia control panel отсутствует вкладка Управление лицензией.

Исходя из совпадения наблюдаемого максимального разрешения VGX дисплея я предполагаю, что в этих типах драйверов по умолчанию используется вид лицензии vApps.

(2) vGPU GRID vApps — для способа подключения vGPU выбор вида лицензии vApps недоступен

В nvidia control panel присутствует вкладка Управление лицензией, однако там нет возможности выбора вида лицензии и сказано, что требуется vWS лицензия.

Насколько я понимаю это связано с тем, что в ESXi выбран Q-series NVIDIA vGPU Deployment Type (я использую NVIDIA GRID vGPU Profile nvidia_rtxa6000-12q).

(4) vGPU GRID vWS — наблюдаемое максимальное разрешение VGX дисплея при подключении через Parsec составляет 3840x2160

Аналогично (2) в nvidia control panel присутствует вкладка Управление лицензией, где нет возможности выбора вида лицензии и сказано, что нужна vWS лицензия.

(5) Passthrough GRID vWS — аналогично (4)

В nvidia control panel присутствует вкладка Управление лицензией и там есть возможность выбора вида лицензии (как показано на рисунке выше).

Благодаря этому после переключения вида лицензии на vWS затем удаётся настроить FullHD разрешение VGX дисплея (как показано на рисунке ниже).

Итого: Full HD VGX доступен только с GRID драйвером и только с vWS лицензией.

Узнать статус лицензии можно и через RDP, и через Parsec во вкладке Управление лицензией, которая доступна в nvidia control panel, установленной с grid драйвером. Очень важно отметить, что если лицензии нет, то через 20 минут FPS снизится до 15 (пруф).

Таким образом, для комфортного облачного гейминга наличие лицензии обязательно!

Простой путь заключается в получении пробной лицензии. Упражнение лучше выполнять через vpn с почтой в собственном домене, например, .me. Тогда письмо с Entitlement Certificate должно прийти сразу, иначе придёт письмо, что заявка на рассмотрении и всё...

Start rabbit hole reference

Но есть и сложный путь, связанный с аудитом работы сервера лицензий. В результате аудита была зафиксирована следующая диаграмма:

(green) Первый вектор аудита связан с тем, что сам сервер лицензий представляет из себя java приложение, а значит используя, например, JetBrains IDE его можно декомпилировать и отлаживать по шагам. Авторская декомпиляция прошла успешно, но отладка зашла в тупик.

(blue) Второй вектор аудита связан с тем, что взаимодействие GPU (осталось не ясно, в лице драйвера или nvidia control panel) с сервером лицензий происходит по сети, а значит используя, например, Wireshark можно узнать содержимое пакетов и реализовать свой сервер лицензий, например, с помощью fastapi. Авторская реализация не заработала, поскольку не получилось воспроизвести заголовки пакетов (видимо что-то не так с CORS).

(grey) Третий вектор аудита связан с анализом библиотек, доступных при установке драйвера GPU. Дело в том, что подобный сервер лицензий использует не только NVIDIA, но и другие компании, поэтому можно поискать решения других аудиторов. Для статического анализа зависимостей библиотек полезен DLL Export Viewer; для динамического Process Explorer и Process Monitor. Отдельно стоит отметить великолепный API Monitor — он хорош всем, однако не хватило возможности видеть не только вызываемый модуль, но и вызывающий. По сути с помощью API Monitor возможно реализовать построение и обход графа вызовов. Но когда дело дошло до IDA Pro и OllyDbg, я понял, что пора остановиться...

End rabbit hole reference

И вот, способ подключения GPU к ВМ выбран (vGPU), гостевой драйвер установлен (GRID), лицензия получена (vWS), разрешение VGX дисплея настроено (Full HD) — пора сравнивать тонкие клиенты!

III. Тонкие клиенты

Содержательно тонкие клиенты различаются по типу данных, получаемых от сервера. Условно можно разделить тонкие клиенты на graphics streaming и video streaming:

• В graphics streaming происходит передача инструкций для рендеринга. Популярным примером является использование Wireshark через X Server с помощью библиотеки GTK. В качестве академического примера можно привести LiveRender.

  Мне неизвестны примеры неакадемических реализаций graphics streaming тонких клиентов для облачного гейминга, поэтому в сравнении их нет. Возможно дело в том, что в случае облачного гейминга объём передаваемых данных больше размера видеопотока, хотя авторы LiveRender и утверждают, что кэширование работает эффективно. Скорее всего, в новых игровых локациях происходят большие задержки из-за промахов в кэше.

• В video streaming происходит передача изменений между кадрами, чаще всего в виде видеопотока, но например в VNC могут передаваться значения пикселей для участков кадров. Для кодирования видеопотока может использоваться аппаратный видеокодек, например, NVENC.

  Наглядным примером неакадемической реализации video streaming тонкого клиента для облачного гейминга является Parsec. Принцип его работы выглядит так: захват необработанных кадров рабочего стола, кодирование необработанных кадров, отправка закодированных кадров по сети, декодирование кадров, визуализация кадров на экране. Для сжатия кадров рабочего стола используются стандарты сжатия видео H.265 и H.264.

Ниже приведена сравнительная таблица тонких клиентов. Для тестирования использовались video streaming клиенты RDP, Parsec, Moonlight, Steam Remote Play. Часть из них использует собственный дисплей, остальные же подключаются напрямую к VGX дисплею. Важно отметить, что VNC, ESXi SVGA и Horizon не участвуют в сравнении, поскольку облачный гейминг не является целевым сценарием их использования.

Удастся ли настроить свой Horizon?

Horizon настроить не удалось, поскольку один Quick Start длиннее всей документации по vGPU...

Какой уровень сервиса покажет триальная версия vGPU с Horizon?

Триальную версию vGPU с Horizon получить не удалось. Раньше для vgputestdrive подходил PIN вида 12345, но похоже эти времена прошли...

Методика сравнения такова: для каждого тонкого клиента производится перезагрузка ВМ и запуск Cyberpunk с максимальными настройками; затем объективно определяется FPS и субъективно визуальное качество (плавность движения кадра, наличие блюра при резких движениях, общий комфорт облачного гейминга); значения остальных характеристик определяются отдельно.

Для измерения FPS на серверной стороне использовался Rivatuner (инструкция по настройке), поскольку FRAPS в Cyberpunk не заработал. Для измерения FPS на клиентской стороне использовался как Rivatuner, так и FRAPS. К сожалению с Parsec ни один из двух счётчиков не заработал, поэтому FPS для Parsec вычислялся по времени обработки кадра.

Неожиданно при запуске на vGPU с 12q профилем (12Гб видеопамяти) FPS на хосте оказался между 22 и 26, чего было недостаточно для комфортного гейминга, а значит и для сравнения тонких клиентов, даже если они выдают тот же FPS (это предельный случай, когда в качестве тонкого клиента выступает монитор, физически подключённый к хосту).

Таким образом, возникла задача увеличения FPS хотя бы до 35, чтобы был зазор для сравнения эффективности тонких клиентов. Для увеличения FPS было сделано следующее:

1. Изменение профиля vGPU с 12q на 24q — не помогло

2. Отключение Spectre/Meltdown — не помогло

3. Переход с vGPU на PassThrough для того, чтобы выбрать RTX A6000 в качестве PhysX — не помогло
   
   Установка конфигурации PhysX есть только при PassThrough подключении

4. Замена типа драйвера: с PassThrough grid на data center tesla и затем на quadrto rtx — не помогло
   
   При замене типа драйвера появилась возможность включить в игре DLSS, но к сожалению из-за типа драйвера при подключении к VGX дисплею напрямую Max Res составило только 1366x768.

5. Включение hardware acceleration в Windows — не помогло

   NOTE: it is recommended to enable upscaling (DLSS) on graphics cards with 16GB or less of VRAM and 1440p or higher resolution.

6. Обновление Cyberpunk с версии 1.6 до версии 1.62 — не помогло
   
   После обновления в разделе DLSS появилась опция Создание кадров DLSS, однако она доступна только с RTX 40 (см. первый скриншот под спойлером ниже). В разделе RTX появилась опция Трассировка пути, она доступна (см. второй скриншот под спойлером ниже).

7. Отключение ECC — не помогло
   
   Отключение ECC (error correcting code) было произведено в ходе теста влияния RTX и DLSS на FPS на хосте. Но поскольку максимальные результаты в тесте были получены с включённым ECC, который точно не ускоряет вычисления, то максимальные результаты могли быть только выше, оставаясь при этом максимальными.

Новые опции в Cyberpunk 1.62

В итоге я пришёл к выводу, что дело в RTX и сравнил FPS на хосте с ним и без него, включив и выключив DLSS. Стоит отметить, что есть 4 разрешения экрана: внутри игры, у дисплея хоста, у тонкого клиента и у монитора пользователя. У меня все 4 разрешения равны 1080p.

Для определения FPS на хосте для PassThrough Quadro RTX я использовал RDP поскольку иначе VGX Max Res 1366x768. Максимум FPS внутри игры задан не был. Таким образом измерялся максимальный FPS игры на хосте.

Hardware acceleration в Windows была включена. Версия Cyberpunk 1.62. В начале тестирования значение ECC было Enabled, а к концу тестирования стало Disabled.

Как запустить Cyberpunk на ВМ с GPU, предоставляемой облаком? Если там Passthrough, то нужен data center драйвер или grid?

Если облако предоставляет vGPU, то для запуска Cyberpunk потребуется установить grid драйвер, лицензия скорее всего будет получена автоматически (стоит заранее уточнить vGPU Profile, чтобы точно получить vWS лицензию, позволяющую настроить Full HD VGX).

Если облако предоставляет PassThrough (или bare metal), то имеет смысл поставить data center tesla или quadro rtx драйвер, а не grid драйвер. Как показано в таблице выше, quadro rtx драйвер позволил получить заметно более высокий FPS чем grid драйвер. Но чтобы настроить Full HD с quadro rtx драйвером необходим тонкий клиент с собственным дисплеем.

Скриншоты PassThrough Quadro RTX RDP Cyberpunk 1.62

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

Кроме того, DLSS также будет выключен во время тестирования, поскольку несмотря на небольшое различие в FPS, для тестирования тонких клиентов, подключающихся к VGX дисплею, нужно Full HD разрешение, которое доступно только с grid драйвером, при установке которого возможность выбрать DLSS пропадает.

И наконец, как быть с RTX?

Как можно видеть в таблице выше, пока даже мощности RTX A6000 (с архитектурой Ampere) недостаточно для комфортной Full HD игры в Cyberpunk с RTX...

Тестирование показывает, что запуск с RTX возможен на PassThrough quadro rtx и data center tesla. Запуск с RTX на PassThrough grid и vGPU grid приводит к вылету игры.

Итого: поиграть с RTX на vGPU не получится, так как grid драйвер несовместим с RTX.

Переходя к долгожданному сравнению тонких клиентов важно отметить, что разрешение внутри игры установлено таким же как у VGX дисплея. А у VGX дисплея в свою очередь настроено Full HD разрешение. Разрешение 720p у VGX не тестируется, поскольку оно мало. Разрешение 4K у VGX также не тестируется, поскольку FPS на хосте и так не велик. Ещё раз подчеркну, что максимум FPS внутри игры не задан.

В тонких клиентах также выбирается разрешение 1080p. Speedtest показывает порядка 100Мбит в обе стороны, поэтому ограничений, связанных с пропускной способностью сети, быть не должно. В тех тонких клиентов, где есть возможность выбрать частоту кадров, тестируется как 30, так и 60 кадров. Мой Full HD монитор поддерживает 120 кадров, поэтому ограничений, связанных с оборудованием на моей стороне, также быть не должно.

Скриншоты Cyberpunk 1.62

По результатам обзора для облачного гейминга подходят: Parsec, Moonlight и Steam :)