Vgpu remotefx что это
KB4570006: обновление для отключения и удаления компонента VGPU RemoteFX в Windows
Обзор
С помощью VGPU remoteFX можно совместно работать с несколькими виртуальными машиными. Эта функция впервые была представлена в Windows 7 и удалена в качестве параметра для пользователей в Windows Server 2019. Мы знаем, что текущая реализация удаленного VGPU является уязвимой к уязвимостям системы безопасности (подробные сведения о CVE см. в разделе «Часто задаваемые действия»). Поскольку новые уязвимости являются архитектурными, а функция уже удалена из более новых версий Windows, обновления безопасности Windows от 13 апреля 2021 г. и все новые версии Windows больше не будут содержать функцию RemoteFX vGPU.
Мы настоятельно рекомендуем вам выбрать альтернативный вариант VGPU.
Временная шкала
Деprecation: RemoteFX vGPU был удален с выпуском Windows 10 версии 1809 и Windows Server 2019.
Отключение: В обновлениях безопасности Windows за июль 2020 г. (14 июля 2020 г.) на всех соответствующих платформах Windows был отключен VGPU RemoteFX.
Удаление: В обновлении для системы безопасности Windows за апрель 2021 г. (13 апреля 2021 г.) будет удален VGPU RemoteFX со всех соответствующих платформ Windows.
Альтернативы
Чтобы снизить потенциальные угрозы безопасности в VGPU RemoteFX, настоятельно рекомендуем пользователям использовать альтернативную технологию VGPU.
Безопасная виртуализация GPU доступна с помощью дискретного назначения устройств (DDA) в выпусках LTSC Windows Server (Windows Server 2016, Windows Server 2019) и SAC Windows Server (Windows Server версии 1803 и более поздних версий).
Вопросы и ответы
Мы больше не будем выпускать обновления для системы безопасности и другие обновления для удаленного VGPU.
Если перед установкой обновления для системы безопасности от 13 апреля 2021 г. с VM связан адаптер VGPU, необходимо удалить его перед повторной запуском VM.
Безопасная виртуализация GPU доступна с помощью дискретного назначения устройств (DDA) в выпусках LTSC Windows Server (Windows Server 2016 и Windows Server 2019) и SAC Windows Server (Windows Server версии 1803 и более поздних версий). Если вы находитесь на более ранней версии Windows, чем Windows 10 версии 1607, рассмотрите возможность обновления.
Дополнительные сведения можно найти в следующих обновлениях для системы безопасности:
Почему не RemoteFX, а также подробнее о технологиии NVIDIA GRID VGPU
Довольно давно я знаком с гипервизором от компании Microsoft под названием Hyper-V. Надо отметить, что данный гипервизор с каждым следующим поколением серверной платформы Windows Server становится всё более функциональным и интуитивно понятным для администрирования. В PowerShell добавляются новые командлеты, позволяющие легко управлять гипервизором. Появляется отличная возможность реализовывать с помощью скриптов даже такие необходимые задачи, как резервное копирование виртуальных машин и создание снапшотов по расписанию в планировщике без использования сторонних и довольно дорогостоящих программ. Администрировать Hyper-V легко, производительность гипервизора не вызывает нареканий, постоянно растет список операционных систем, имеющих либо установленные службы интеграции с гипервизором, либо имеющих возможность установить такие службы, либо поддерживающих Hyper-V благодаря модулям ядра. Еще совсем недавно состоялся релиз FreeBSD 10.0, первой из BSD систем, которая легко и непринужденно устанавливалась в качестве гостевой на гипервизор от Microsoft, и которая избавилась от детских болячек, вроде ограниченного размера виртуального жесткого диска и возможности использования только устаревшего сетевого адаптера (legacy или эмулированного), чья скорость не может превышать 100мбит/сек, в то время как физический сетевой адаптер является гигабитным. В общем, как может показаться, тенденция к улучшению имеет ну очень положительную динамику. Именно поэтому изначально мы занялись поиском ответа на вопрос, о том, существует ли возможность использования физической видеокарты в гостевой операционной системе Hyper-V. Ответ, как нам казалось тогда, не заставил себя долго ждать и уже через 5 минут, судя по статьям в интернете, мы были уверены, что такая возможность существует и, более того, она качественно реализована разработчиками Hyper-V. Как оказалось, мы жестоко ошибались, но обо всем по порядку.
Microsoft предложила в качестве решения технологию RemoteFX, которую изначально разрабатывала компания Calista Technologies, которая в последствии была приобретена Microsoft. Сама технология имеет очень весомые аппаратные требования как к серверу виртуализации, так и к видеокарте, которая в дальнейшем будет использоваться гостевой операционной системой посредством этой технологии. Требования заключаются в том, что сам сервер должен иметь CPU с поддержкой SLAT (EPT on Intel, NPT/RVI on AMD), а вот с GPU все еще веселее. Вот собственно требования и рекомендации, озвученные самими Microsoft:
| Rank | NVIDIA | AMD |
|---|---|---|
| Best | NVIDIA Grid 1. Grid K1 2. Grid K2 | AMD FirePro series 1. AMD FirePro S10000 2. AMD FirePro S9000 3. AMD FirePro S7000 |
| Better | NVIDIA Quadro 1. Quadro K6000 2. Quadro K5000 | AMD FirePro series 1. AMD FirePro V9800P 2. ATI FirePro V9800 |
| Good | AMD FirePro series 1. ATI FirePro V8800 2. ATI FirePro V7800 3. AMD FirePro V7800P 4. ATI FirePro V5800 |
На просторах всемирной сети есть немало руководств по развертыванию RemoteFX на Windows Server. Однако о качественном применении почти ни в одной из этих статей речи не идёт, а в основном статья имеет такой законченный смысл «Поднял, поковырялся, вроде работает, вроде даже шевелится побыстрее, вроде даже нагрузку на центральный процессор снизили. Для чего делал? Черт его знает».
Так вот, я хочу рассказать вам о нашем опыте поиска решения задачи по расширению возможностей виртуальных машин в обработке 3D-графики. Перед нами стояла довольно чётко обрисованная задача. Нам нужно было сделать так, чтобы пользователи удаленных рабочих столов терминального сервера, развернутого на платформе Windows Server 2012 R2, смогли как минимум качественно просматривать различные 3D чертежи и сборки в специализированных viewer-ах, а как максимум и сами могли нет-нет, да и запустить различные CAD программы.
Первоначальной идеей стало развертывание RemoteFX на Windows Server 2012R2. Сказано – сделано. В наличии имелась серверная платформа DELL PowerEdge R720, оснащенный двумя процессорами Intel Xeon CPU E5-2670 v2 @ 2.50GHz поддерживающими SLAT, а также вычислительный графический модуль NVIDIA GRID K2. На сервер была установлена операционная система Windows Server 2012R2 standard с графической оболочкой, была развернута служба Hyper-V и настроен RemoteFX. На самом деле, тогда мы думали, что это окончательное решение и технология RemoteFX нас полностью устроит. Однако, в дальнейшем мы узнали, что Microsoft накладывает на технологию и существенные программные требования, что в качестве гостевой операционной системы, способной использовать трехмерный графический адаптер RemoteFX, могут выступать только операционные системы Windows 7 и 8 и только в редакциях Ultimate и Enterprise. Не совсем справедливо конечно, учитывая то, что сам гипервизор по заявлениям своих разработчиков поддерживает уйму других операционных систем.
Стало понятно, что наша цель использовать графический адаптер в виртуальном терминальном сервере, который развернут на Windows Server 2012R2, останется неосуществимой. Ладно, работаем с тем, что есть. Так что-же у нас есть? Совсем немного. Всего-то возможность установки в качестве гостевой операционной системы Windows 7-8 Ultimate-Enterprise с возможностью подключения к ним только одного пользователя. И даже распрекрасная библиотека RDP Wrapper не в состоянии решить этой проблемы. К тому-же, как нам стало известно по результатам производительности, трехмерный графический адаптер RemoteFX практически не умеет работать с таким API, как OpenGL, который используют большинство CAD программ, а вместо этого поддерживает полностью только проприетарную разработку Microsoft только для Windows – Direct3D. Об этом совсем скромно-скромно заявляют лишь две строчки в описании технологии RemoteFX на сайте Microsoft:
«Support in Windows Server 2012 R2 is provided for DX 11.0, DirectCompute, and C++ AMP. Most of the latest graphics cards will support OpenGL 4.0 and OpenCL 1.1 or later, but these APIs are currently unsupported by RemoteFX in Windows Server 2012 R2.»
Что это, проприетарная разработка для поддержания возможности развертывания терминального сервера на основе виртуальных машин, предложенной в последнем поколении Windows Server? Сложно ответить на этот вопрос. Однако, ясно только одно, технология RemoteFX неприменима для решения поставленной перед нами задачи, особенно ввиду чрезмерно завышенных аппаратных и программных требований к платформе, серверу и гостевым операционным системам. Все эти требования мы, конечно, готовы удовлетворить, но получить в результате готовое решение с крайне сомнительным функционалом – это расточительство.
Именно поэтому поиск не прекратился и, к своему стыду, мы первый раз обратили внимание на то, что пишет сама NVIDIA, о разработанном им графическом вычислительном модуле и его применении. Подробнее можно прочесть здесь, а если коротко, то NVIDIA создала технологию NVIDIA GRID vGPU, благодаря которой графические команды каждой виртуальной машины передаются напрямую в GPU, без трансляции гипервизором. Один физический графический модуль, благодаря драйверу, имеет несколько профилей виртуального GPU c различным количеством ядер и дискретной графической памяти. Вот таблица доступных виртуальных профилей для графических плат NVIDIA GRID:
| Графическая плата NVIDIA GRID | Профиль виртуального GPU | Графическая память | Максимальное число дисплеев на пользователя | Максимальное разрешение дисплея | Максимальное число пользователей на графическую плату |
|---|---|---|---|---|---|
| GRID K2 | K280Q K260Q K240Q K220Q | 4ГБ 2ГБ 1ГБ 512МБ | 4 4 2 2 | 2560×1600 2560×1600 2560×1600 2560×1600 | 2 4 8 16 |
| GRID K1 | K180Q K160Q K140Q K120Q | 4ГБ 2ГБ 1ГБ 512МБ | 4 2 2 2 | 2560×1600 2560×1600 2560×1600 2560×1600 | 4 8 16 32 |
Всё предельно просто и прекрасно. Драйвер имеет возможность выделять из аппаратной платформы платы виртуальные профили, отличающиеся друг от друга количеством графических ядер и памяти, которые могут стать аналогом физической видеокарты в виртуальной машине. В то время, как технология RemoteFX – всего лишь программная прослойка между виртуальной машиной и реальной графической платой, которая выборочно передает на обработку ту или иную графику. Зачем тогда Microsoft рекомендует к использованию графическую плату, чей функционал в полной мере не поддерживается возможностями их гипервизора? Зачем рекомендовать эту плату к использованию, если гипервизор, написанный ими, не идет по пути развития концепции, предложенной производителями графической платы? Не понятно. Однако, надо отметить, что в описании самой технологии NVIDIA GRID VGPU на сайте NVIDIA, не говорится ни слова (и слава богу) о гипервизоре Microsoft, а вместо этого упоминаются такие разработчики, как VMware c vSphere и Citrix со своим XenServer.
Было решено попробовать в качестве гипервизора XenServer 6.5 от Citrix, чей функционал в редакции Enterprise как раз поддерживает распределение виртуальных графических профилей между виртуальными машинами. Хоть это и не имеет никакого отношения к статье, всё же отмечу, что установка и настройка сервера простая и интуитивно понятная до безобразия. Сервер был установлен и активирован триальной лицензией на 90 дней, которую можно получить, с учетом количества сокетов хоста, за 5 минут, зарегистрировавшись на сайте разработчиков. После активации функция распределения графических профилей становится доступной в XenCenter. К сожалению, для загрузки пока доступны драйвера исключительно для операционных систем Windows, однако радует уже то, что графический профиль имеет возможность устанавливаться не только на версии Windows 7-8 Ultimate-Enterprise, но и на другие операционные системы Microsoft такие как Windows 7-8 других редакций и Windows Server 2008-2012, из коробки поддерживает OpenGL 4.4 и DirectX 11 и OpenCL, а также не имеет ограничений на количество одновременных подключений средствами удаленного рабочего стола к виртуальной машине.
Чтобы оценить качество работы виртуальных графических профилей, в качестве гостевой была установлена операционная система Windows 8.1_x64_Enterprise, в настройках виртуальной машины поочередно добавлялись первые три профиля (K280Q, K260Q, K240Q), которые считаются максимально производительными в порядке убывания, и с каждым графическим профилем было запущено по 4 бенчмарка, тестирующих производительность 3D графики с использованием API OpenGL и Direct3D. Чтобы сравнение не казалось чрезмерно-абстрактным, было принято решение сравнить результаты бенчмарков, запущенных на ВМ, с результатами этих же бенчмарков запущенных на физической машине, имеющей схожие характеристики. Коротко о технических характеристиках виртуальной и физической машины можно узнать из таблицы представленной ниже.
| ОС | ЦП | ОЗУ | Видеоадаптер | |
|---|---|---|---|---|
| ФМ | Windows 8.1 x64 Enterprise | Inter Core(TM) CPU i5-4670 @ 3.40GHz | 12ГБ | Nvidia GeForce GTX 650 |
| ВМ | Windows 8.1 x64 Enterprise | Inter Xeon CPU E5-2670 v2 @ 2.50GHz | 12ГБ | Nvidia GRID VGPU K280Q || K260Q || K240Q. |
В таблицах с результатами работы бенчмарков я буду указывать только название графического адаптера.
Итак, первым бенчмарком будет SPECviewperf 12.0.2, который многими специалистами почитается как эталонный бенчмарк для тестирования графики различных CAD программ. Кому интересно, подробнее тут. Результаты в таблице ниже. Разрешение окна везде 1900×1060 (по умолчанию в бенчмарке).
| Тест | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Catia-04 | 9.06 | 17.16 | 31.83 | 12.14 |
| Creo-01 | 9.21 | 17.85 | 34.41 | 17.72 |
| Energy-01 | 0.43 | 0.72 | 0.74 | 0.18 |
| Maya-04 | 22.45 | 6.14 | 13.99 | 2.85 |
| Medical-01 | 6.18 | 15.17 | 18.76 | 15.38 |
| Showcase-01 | 14.99 | 11.14 | 32.80 | 10.84 |
| Snx-02 | 2.07 | 18.31 | 34.80 | 18.41 |
| SolidWorks-03 | 20.56 | 19.02 | 38.14 | 20.79 |
Все результаты выкладываю как есть. Немного смутило меня, что профиль K260Q по идее должен быть «слабее», чем K280Q, однако показал более выдающиеся результаты. Перепроверил, запустив тест еще раз на обоих профилях и пришел к выводу, что показания стабильные (не рандомные) и хоть и отличаются от первоначальных, но в разумных пределах 0.2-0.4.
Следующим бенчмарком, а вернее набором различных бенчмарков для тестирования графики OpenGL стал GpuTest с сайта geeks3d.com, подробнее можно узнать здесь. Результаты в таблице ниже в формате (points/FPS). Все тесты произведены в полноэкранном режиме 1920×1080.
| Тест | GTX 650 (points/FPS) | K280Q (points/FPS) | K260Q (points/FPS) | K240Q (points/FPS) |
|---|---|---|---|---|
| FurMark (OpenGL 2.1/3.0) | 1214/20 | 2068/34 | 1790/29 | 1619/26 |
| GiMark (OpenGL 3.3) | 960/15 | 1630/27 | 1578/26 | 1604/26 |
| PixMark Julia FP32 (OpenGL 2.1/3.0) | 6724/111 | 2231/37 | 3874/64 | 3364/56 |
| PixMark Julia FP64 (OpenGL 4.0) | 490/8 | 1046/17 | 1216/20 | 1082/18 |
| Plot3D (OpenGL 2.1/3.0) | 39817/664 | 2289/38 | 2299/38 | 2296/38 |
| TessMark x16 (OpenGL 4.0) | 13458/224 | 1545/25 | 1329/22 | 1542/25 |
| TessMark x64 (OpenGL 4.0) | 3039/50 | 1511/25 | 1419/23 | 1535/25 |
| Triangle (OpenGL 2.1/3.0) | 145268/2421 | 3748/62 | 3871/64 | 3757/62 |
Следующим бенчмарком стал RedSDK turbine benchmark от компании REDWAY3D. Подробнее тут. Результаты в таблице ниже. Все тесты произведены в полноэкранном режиме 1920×1080.
| Тест | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| Real-time viewport | 1623 | 1018 | 368 | 400 |
| High quality real-time | 1800 | 1576 | 355 | 366 |
| Dynamic ambient occlusion | 1311 | 2459 | 2378 | 2418 |
| Hybrid ray-tracing | 1114 | 414 | 413 | 399 |
| Total score | 1437 | 1131 | 599 | 614 |
Последним бенчмарком стала бесплатная версия Heaven Benchmark 4.0 от разработчиков Unigine. Подробнее тут. Выбор на него пал в том числе потому, что он может протестировать графику Direct3D. Все тесты произведены в окне разрешением 1280×720 по причине того, что бенчмарк не захотел запускаться в полноэкранном режиме на виртуальных машинах по неизвестным мне причинам, выдавая ошибку. Результаты в таблицах ниже.
| OpenGL | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| FPS | 44.9 | 56.8 | 54.0 | 56.3 |
| Score | 1131 | 1432 | 1361 | 1418 |
| Min FPS | 11.2 | 13.2 | 8.8 | 11.8 |
| Max FPS | 83.7 | 66.1 | 66.0 | 66.0 |
| Direct3D 11 | GTX 650 | K280Q | K260Q | K240Q |
|---|---|---|---|---|
| FPS | 46.9 | 69.4 | 34.2 | 57.4 |
| Score | 1183 | 1747 | 862 | 1446 |
| Min FPS | 10.7 | 9.2 | 6.9 | 9.9 |
| Max FPS | 88.1 | 137.5 | 93.8 | 67.5 |
Никаких выводов из произведенных мною тестов делать не буду, лучше оставлю это для общественности. Если честно, то результаты тестов мне не до конца понятны и если читающему есть чем качественно прокомментировать их, то буду только рад.
Подводя итоги скажу, что все используемые в нашей компании CAD программы и иной софт успешно устанавливаются и запускаются на виртуальных машинах. Осталось дать поработать с удаленным рабочим столом специалисту, использующему эти программы и пусть он вынесет окончательный вердикт о возможности использования этого решения. Также хочу подчеркнуть, что писал эту статью вовсе не от безделья, а именно потому что, когда сам искал решение поставленной передо отделом ИТ задачи, не увидел подобных статей, полностью раскрывающих различия разных технологий проброса возможностей графической платы в виртуальную машину, не увидел статей, в которых описано качественное применение данных технологий.
Надеюсь, опыт нашего отдела ИТ кому-нибудь пригодится. Благодарю за внимание.
Развертывание графических устройств с помощью vGPU RemoteFX
применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Microsoft Hyper-V Server 2016
Из соображений безопасности процессор RemoteFX vGPU по умолчанию отключен для всех версий Windows, начиная с обновления для системы безопасности за 14 июля 2020 г., и удален, начиная с обновления для системы безопасности за 13 апреля 2021 г. См. KB 4570006.
функция gpu для RemoteFX позволяет нескольким виртуальным машинам совместно использовать физический GPU. визуализация и вычисление ресурсов совместно используются виртуальными машинами, что делает RemoteFXные виртуальные машины подходящими для высокопроизводительных рабочих нагрузок, когда выделенные ресурсы GPU не требуются. например, в службе VDI RemoteFX виртуальный графический процессор можно использовать для разгрузки затрат на визуализацию приложений в GPU, что приводит к снижению нагрузки на цп и улучшению масштабируемости служб.
Требования к RemoteFX vGPU
Требования к системе узла:
Требования к гостевым виртуальным машинам:
Дополнительные рекомендации для гостевых виртуальных машин:
включение RemoteFXного видеопроцессора
чтобы настроить RemoteFXный виртуальный жесткий процессор на узле Windows Server 2016:
по умолчанию RemoteFX виртуальный графический процессор будет использовать все доступные и поддерживаемые gpu. чтобы ограничить количество gpu, используемых RemoteFXным виртуальным графическим процессором, выполните следующие действия.
Настройка трехмерного адаптера vGPU RemoteFX
Вы можете использовать пользовательский интерфейс диспетчера Hyper-V или командлеты PowerShell, чтобы настроить трехмерный графический адаптер vGPU RemoteFX.
настройка RemoteFX виртуального устройства с помощью диспетчера Hyper-V
Останавливает виртуальную машину, если она выполняется в данный момент.
откройте диспетчер Hyper-V, перейдите к Параметры вм, а затем выберите добавить оборудование.
выберите RemoteFX трехмерная графическая плата, а затем нажмите кнопку добавить.
Задайте максимальное число мониторов, максимальное разрешение монитора и используемой видеопамяти, либо оставьте значения по умолчанию.
настройка RemoteFXного gpu с помощью командлетов PowerShell
Используйте следующие командлеты PowerShell для добавления, проверки и настройки адаптера:
Мониторинг производительности
производительность и масштабирование RemoteFX службы с поддержкой виртуальных gpu определяется различными факторами, такими как количество gpu в системе, общая память gpu, объем системной памяти и скорость памяти, число ядер цп и тактовая частота цп, скорость хранения и реализация NUMA.
Память системы узла
для каждой виртуальной машины, поддерживающей виртуальный графический процессор, RemoteFX использует системную память как в гостевой операционной системе, так и на сервере узла. Гипервизор гарантирует доступность системной памяти для гостевой операционной системы. На узле каждому виртуальному рабочему столу с поддержкой виртуальных рабочих столов необходимо объявить требования к системной памяти гипервизору. Когда запускается виртуальный рабочий стол с поддержкой виртуальных рабочих столов, гипервизор резервирует дополнительный объем системной памяти на узле.
требования к памяти для сервера с поддержкой RemoteFX являются динамическими, так как объем памяти, потребляемой на сервере с поддержкой RemoteFX, зависит от числа мониторов, связанных с виртуальными рабочими столами с поддержкой виртуальных рабочих столов, и максимального разрешения этих мониторов.
Видеопамять основного GPU узла
Каждый виртуальный рабочий стол с поддержкой виртуальных рабочих столов использует аппаратную видеопамять GPU на сервере узла для подготовки к просмотру рабочего стола. Кроме того, кодек использует видео-память для сжатия отображаемого экрана. Объем памяти, необходимый для отрисовки и сжатия, непосредственно зависит от количества мониторов, подготовленных для виртуальной машины. Объем зарезервированной видеопамяти зависит от разрешения экрана системы и количества мониторов. Некоторым пользователям требуется более высокое разрешение экрана для определенных задач, но существует большая масштабируемость с более низкими параметрами разрешения, если все остальные параметры остаются постоянными.
ЦП узла
Гипервизор планирует размещение и виртуальные машины на ЦП. дополнительная нагрузка на узел с поддержкой RemoteFX увеличивается, так как система запускает дополнительный процесс (rdvgm.exe) на виртуальном рабочем столе с поддержкой виртуальных рабочих столов. Этот процесс использует драйвер графического устройства для выполнения команд GPU. Кодек также использует ЦП для сжатия данных экрана, которые необходимо отправить обратно клиенту.
Большее число виртуальных процессоров означает лучшее взаимодействие с пользователем. Мы рекомендуем выделить не менее двух виртуальных процессоров на виртуальный рабочий стол с поддержкой виртуальных рабочих столов. Мы также советуем использовать архитектуру x64 для виртуальных рабочих столов с поддержкой GPU, так как производительность виртуальных машин x64 лучше по сравнению с виртуальными машинами x86.
Вычислительная мощность процессора
У каждого виртуального рабочего стола с поддержкой виртуальных рабочих столов есть соответствующий процесс DirectX, выполняемый на сервере узла. этот процесс воспроизводит все команды графики, полученные от RemoteFX виртуального рабочего стола, на физический графический процессор. Это аналогично одновременному запуску нескольких приложений DirectX на одном физическом GPU.
как правило, графические устройства и драйверы настроены на выполнение только нескольких приложений на рабочем столе, но RemoteFX растягивает графические процессоры, чтобы продолжить работу. вгпус поставляются со счетчиками производительности, которые измеряют ответ GPU на запросы RemoteFX и позволяют убедиться, что gpu не растягиваются слишком далеко.
Когда GPU не хватает ресурсов, операции чтения и записи выполняются длительное время. Администраторы могут использовать счетчики производительности, чтобы выяснить, когда следует настраивать ресурсы и предотвращать время простоя для пользователей.
дополнительные сведения о счетчиках производительности для мониторинга RemoteFX поведения виртуальных gpu см. в статье диагностика проблем производительности графики в удаленный рабочий стол.