Видеокарта с удаленным доступом

Виртуальная видеокарта QXL на реальном железе

QXL vs. VNC

Виртуальная видеокарта QXL изначально была разработана для использования в эмуляторе KVM для улучшения вывода графики через протокол SPICE. С недавнего времени виртуальная видеокарта QXL может использоваться на реальном оборудовании для предоставления удаленного доступа по сети по протоколу SPICE к экрану сервера под управлением X-сервера, как альтернатива VNC-серверу.

Для запуска VNC-сервера нужен X-сервер, который должен быть запущен локально и которому для работы нужна видеокарта. В отличие от VNC-сервера, SPICE-сервер встроен в драйвер виртуальной видеокарты QXL, а как следствие может запускать X-сервер без наличия реальной видеокарты.

Работа с компьютером без использования видеокарты может использоваться не только для снижения стоимости конфигурации и использования, но также и для проброса всех установленных PCI-видеокарт в виртуальные машины спомощью технологий Vt-d и IOMMU.

Виртуальная видеокарта QXL налагает некоторые ограничения, которые необходимо учитывать при принятии решения о её использовании:

  1. Работа по выводу изображения переносится с графического процессора и памяти видеокарты на центральный процессор и оперативную память компьютера, что в свою очередь отражается на производительности. Хотя если процессор компьютера обладает несколькими ядрами и достаточным объемом оперативной памяти возрастание потребления вычислительных ресурсов будет не столь заметно.
  2. В силу переноса вычислений по обработке вывода графики с видеокарты на компьютер снижается не только производительность но и становятся недоступными некоторые возможности. Например: ускорение 3D-графики через аппаратный рендеринг, поддержка ускорения видео через оверлей и т.д. и т.п.
  3. Невозможность отладки загрузки до момента запуска X-сервера. Отладка в случае возникновения ошибок на этапе згрузки осуществляется путем подключения видео карты либо использованием SSH или вывода консоли на последовательный порт.
  4. В отличае от VNC-сервера у SPICE-сервера имеется баг суть которго заключается в том что XKB в результате запуска QXL отваливается по этой причине необходимо каждый раз при запуске инициализировать раскладки с помощью команды*:
  • В отличие от виртуальной машины, реальный компьютер не имеет виртуального канала для работы с гипервизором в следствие чего работа с буфером обмена, проброс USB-устройств будут не доступны.
  • После установки QXL-видеокарты Х-сервер не будет использовать реальную видеокарту.
  • Таким образом использование виртуальной видеокарты QXL неудобно для доступа к рабочим компьютерам напрямую, но может использоваться на серверах например на узлах виртуализации. Однако стоит отметить что при желании можно виртуализовать рабочие компьютеры и удаленно пробросить в них необходимое USB-оборудование обеспечив тем самым удаленный доступ.

    Установка и настройка

    В качестве примера проведем эксперимент по настройке удаленного доступа через SPICE-сервер на виртуальных машинах под управлением Ubuntu 12.04 и Fedora 17 после настройки из которых удалим видеоакарты. Если эксперимент с виртуальными машинами у Вас удастся можно переходить к реальному железу.

    Прежде чем приступить к эксперименту, на компьютерах под управлением операционной системы GNU/Linux семейства Ubuntu 12.04 далее (Ubuntu) подключаем репозиторий repo.umvirt.org:

    Внимание: в настоящее время в репозитории представлены пакеты только для платформы amd64!

    На компьютерах под управлением Fedora17 (далее Fedora) подключать репозиторий не нужно. Другие версии и дистрибутивы не тестировались.

    Для того чтобы приступить к использованию QXL-видеокарты нужно:

      Установить QXL-драйвер (как минимум версии 0.0.17) и SPICE-сервер.
      Fedora:

    Установить и настроить SSH для удаленного доступа к консоли:
    Fedora:

    Если SSH-соединение работает переходим к следующему этапу

    Явно прописать в настройках X-сервера в файле /etc/X11/xorg.conf использование видеокарты QXL и настройки SPICE-сервера:

    Если файл не существует его следует создать. Для удоства, через SSH и буфер обмена вы можете вставить вышеуказанный код в файл.

    На машине клиента нужно установить необходимые пакеты:
    Fedora:

    Подключиться клиентом к SPICE-сервру. Например, для доступа к SPICE-серверу расположенному по адресу 192.168.122.10 выполним команду:

    В доказательство того, что SPICE-сервер может запускать X-сервер без видеокарты, привожу скриншоты Fedora и Mint 13 Maya (семейство Ubuntu 12.04) c выводом списка PCI устройств для подтверждения с помощью команды lspci:

    1. Fedora 17
    2. Mint 13 Maya
    Читайте также:  8 новое питание процессора

    *Способы автоматизации загрузки раскладки приведены по ссылке

    Источник

    CUDA и удалённый GPU

    CUDA всем хороша, пока под рукой есть видеокарта от Nvidia. Но что делать, когда на любимом ноутбуке нет Nvidia видеокарты? Или нужно вести разработку в виртуальной машине?

    Я постараюсь рассмотреть в этой статье такое решение, как фреймворк rCUDA (Remote CUDA), который поможет, когда Nvidia видеокарта есть, но установлена не в той машине, на которой предполагается запуск CUDA приложений. Тем, кому это интересно, добро пожаловать под кат.

    rCUDA (Remote CUDA) — фреймворк, реализующий CUDA API, позволяющий использовать удалённую видеокарту. Находится в работоспособной бета-версии, доступен только под Linux. Основная цель rCUDA — полная совместимость с CUDA API, вам не нужно никак модифицировать свой код, достаточно задать специальные переменные среды.

    Что такое rCUDA

    rCUDA (Remote CUDA) — фреймворк, реализующий CUDA API, позволяющий использовать для CUDA вычислений видеокарту, расположенную на удалённой машине, не внося никаких изменений в ваш код. Разработан в политехническом университете Валенсии (rcuda-team).

    Ограничения

    На данный момент поддерживаются только GNU/Linux системы, однако разработчики обещают поддержку Windows в будущем. Текущая версия rCUDA, 18.03beta, совместима с CUDA 5-8, то есть CUDA 9 не поддерживается. Разработчиками заявлена полная совместимость с CUDA API, за исключением графики.

    Возможные сценарии использования

    Краткая инструкция

    Тестовая конфигурация

    Тестирование проводилось на следующей конфигурации:

    Сервер:
    Ubuntu 16.04, GeForce GTX 660

    Клиент:
    Виртуальная машина с Ubuntu 16.04 на ноутбуке без дискретной видеокарты.

    Получение rCUDA

    Cамый сложный этап. К сожалению, на данный момент единственный способ получить свой экземпляр этого фреймворка — заполнить соответствующую форму запроса на официальном сайте. Впрочем, разработчики обещают отвечать в течение 1-2 дней. В моём случае мне прислали дистрибутив в тот же день.

    Установка CUDA

    Для начала необходимо установить CUDA Toolkit на сервере и клиенте (даже если на клиенте нет nvidia видеокарты). Для этого можно скачать его с официального сайта или использовать репозиторий. Главное, использовать версию не выше 8. В данном примере используется установщик .run с оффициального сайта.

    Важно! На клиенте следует отказаться от установки nvidia драйвера. По умолчанию CUDA Toolkit будет доступен по адресу /usr/local/cuda/. Установите CUDA Samples, они понадобятся.

    Установка rCUDA

    Распакуем полученный от разработчиков архив в нашу домашнюю директорию на сервере и на клиенте.

    Проделать эти действия нужно как на сервере, так и на клиенте.

    Запуск демона rCUDA на сервере

    Замените на имя вашего пользователя. Используйте ./rCUDAd -iv, если хотите видеть подробный вывод.

    Настройка клиента

    Откроем на клиенте терминал, в котором в дальнейшем будем запускать CUDA код. На стороне клиента нам необходимо «подменить» стандартные библиотеки CUDA на библиотеки rCUDA, для чего добавим соответствующие пути в переменную среды LD_LIBRARY_PATH. Также нам необходимо указать количество серверов и их адреса (в моём примере он будет один).

    Сборка и запуск

    Попробуем собрать и запустить несколько примеров.

    Пример 1

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

    Важно! Без EXTRA_NVCCFLAGS=—cudart=shared чуда не получится
    Замените на путь, который вы указали для CUDA Samples при установке CUDA.

    Запустим собранный пример:

    Если вы всё сделали правильно, результат будет примерно таким:

    Самое главное, что мы должны увидеть:

    Device0 = GeForce GTX 660
    Result = PASS

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

    Важно! Если вывод приложения начинается со строк вида:

    значит необходимо добавить на сервере и на клиенте в файл «/etc/security/limits.conf» следующие строки:

    Таким образом, вы разрешите всем пользователям (*) неограниченное (unlimited) блокирование памяти (memlock). Еще лучше будет заменить * на нужного пользователя, а вместо unlimited подобрать менее жирные права.

    Пример 2

    Теперь попробуем что-то поинтереснее. Протестируем реализацию скалярного произведения векторов с использованием разделяемой памяти и синхронизации («Технология CUDA в примерах» Сандерс Дж. Кэндрот Э. 5.3.1).

    В данном примере мы рассчитаем скалярное произведение двух векторов размерностью 33 * 1024, сравнивая ответ с результатом, полученным на CPU.

    Читайте также:  Ноутбук с процессором core i3 оперативной памятью

    Сборка и запуск:

    Такой результат говорит нам, что всё у нас хорошо:

    Пример 3

    Запустим еще один стандартный тест CUDA- matrixMulCUBLAS (перемножение матриц).

    [Matrix Multiply CUBLAS] — Starting…
    GPU Device 0: «GeForce GTX 660» with compute capability 3.0

    MatrixA(640,480), MatrixB(480,320), MatrixC(640,320)
    Computing result using CUBLAS. done.
    Performance= 436.24 GFlop/s, Time= 0.451 msec, Size= 196608000 Ops
    Computing result using host CPU. done.
    Comparing CUBLAS Matrix Multiply with CPU results: PASS

    NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

    Performance= 436.24 GFlop/s,
    Comparing CUBLAS Matrix Multiply with CPU results: PASS

    Безопасность

    Я не нашёл в документации к rCUDA упоминания о каком-либо способе авторизации. Думаю, на данный момент самое простое, что можно сделать, это открыть доступ к нужному порту (8308) только с определённого адреса.

    При помощи iptables это будет выглядеть так:

    В остальном оставляю вопрос безопасности за рамками данного поста.

    Источник

    Бюджетные VPS с видеоадаптерами: сравнение российских провайдеров

    Считается, будто виртуальные серверы с vGPU стоят дорого. В небольшом обзоре я попробую опровергнуть этот тезис.

    Поиск в сети сходу выдает аренду суперкомпьютеров на NVIDIA Tesla V100 или серверов с мощными выделенными GPU попроще. Подобные услуги есть, к примеру, у МТС, Reg.ru или Selectel. Их месячная стоимость измеряется десятками тысяч рублей, а мне хотелось найти более дешевые варианты для приложений OpenCL и/или CUDA. Бюджетных VPS с видеоадаптерами на российском рынке не так много, в небольшой статье я сравню их вычислительные возможности с помощью синтетических тестов.

    Участники

    В список кандидатов на участие в обзоре попали виртуальные серверы хостеров 1Gb.ru, GPUcloud, RuVDS, UltraVDS и VDS4YOU. С получением доступа особых проблем не возникло, поскольку почти у всех провайдеров есть бесплатный тестовый период. У UltraVDS бесплатного теста официально нет, но договориться оказалось несложно: узнав о публикации, сотрудники поддержки накинули мне нужную для заказа VPS сумму на бонусный счет. На этом этапе с дистанции сошли виртуальные машины VDS4YOU, потому что для бесплатного тестирования хостер требует предоставить скан удостоверения личности. Понимаю, что от злоупотреблений нужно защищаться, но для проверки вполне достаточно реквизитов паспорта или, например, привязки аккаунта в социальной сети — ее требует 1Gb.ru.

    Конфигурации и цены

    Для тестирования были взяты машины среднего уровня, стоимостью менее 10 тысяч рублей в месяц: 2 вычислительных ядра, 4 ГБ оперативной памяти, SSD на 20 — 50 ГБ, vGPU с 256 МБ VRAM и Windows Server 2016. Перед оценкой производительности VDS посмотрим на их графические подсистемы вооруженным взглядом. Созданная компанией Geeks3D утилита GPU Caps Viewer позволяет получить подробную информацию об используемых хостерами аппаратных и программных решениях. С ее помощью можно увидеть, например, версию видеодрайвера, объем доступной видеопамяти, а также данные о поддержке OpenCL и CUDA.

    1Gb.ru GPUcloud RuVDS UltraVDS
    Виртуализация Hyper-V OpenStack Hyper-V Hyper-V
    Вычислительных ядер 2*2,6 ГГц 2*2,8 ГГц 2*3,4 ГГц 2*2,2 ГГц
    RAM, ГБ 4 4 4 4
    Накопитель, ГБ 30 (SSD) 50 (SSD) 20 (SSD) 30 (SSD)
    vGPU RemoteFX NVIDIA GRID RemoteFX RemoteFX
    Видеоадаптер NVIDIA GeForce GTX 1080 Ti NVIDIA Tesla T4 NVIDIA Quadro P4000 AMD FirePro W4300
    vRAM, МБ 256 4063 256 256
    Поддержка OpenCL + + + +
    Поддержка CUDA +
    Цена в месяц (при оплате за год), руб. 3494 (3015) 7923,60 1904 (1333) 1930 (1351)
    Оплата за ресурсы, руб нет CPU = 0,42 руб/час,
    RAM = 0,24 руб/час,
    SSD = 0,0087 руб/час,
    OS Windows = 1,62 руб/час,
    IPv4 = 0,15 руб/час,
    vGPU (T4/4Gb) = 7 руб/час.
    от 623,28 + 30 за инсталляцию нет
    Тестовый период 10 дней 7 дней или больше по договоренности 3 дня при помесячной тарификации нет

    Из рассмотренных провайдеров только GPUcloud использует виртуализацию OpenStack и технологию NVIDIA GRID. Из-за большого объема видеопамяти (доступны профили на 4, 8 и 16 ГБ) услуга стоит дороже, но у клиента будут работать приложения OpenCL и CUDA. Остальные претенденты предлагают vGPU и с меньшим объемом VRAM, созданные с использованием Microsoft RemoteFX. Стоят они значительно дешевле, но поддерживают только OpenCL.

    Тестирование производительности

    GeekBench 5

    С помощью этой популярной утилиты можно измерить производительность графической подсистемы для приложений OpenCL и CUDA. На приведенной ниже диаграмме показан сводный результат, а более подробные данные для виртуальных серверов 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS доступны на сайте разработчика бенчмарка. Если их открыть, обнаружится интересный факт: GeekBench показывает объемы VRAM, намного превышающие заказанные 256 МБ. Тактовая частота центральных процессоров также может быть больше заявленной. В виртуальных средах это обычное явление — многое зависит от загруженности физического хоста, на котором работает VPS.

    Читайте также:  Все типы корпусов процессора

    Разделяемые «серверные» vGPU слабее производительных «настольных» видеоадаптеров, если использовать их для тяжеловесных графических приложений. Такие решения предназначены в основном для вычислительных задач. Для оценки их эффективности были проведены другие синтетические тесты.

    FAHBench 2.3.1

    Для всестороннего анализа вычислительных возможностей vGPU этот бенчмарк не подходит, но с его помощью можно сравнить производительность видеоадаптеров разных VPS в сложных расчетах с использованием OpenCL. Проект распределенных вычислений Folding@Home решает узкую задачу компьютерного моделирования свертывания белковых молекул. Исследователи пытаются понять причины возникновения связанных с дефектными белками патологий: болезней Альцгеймера и Паркинсона, коровьего бешенства, рассеянного склероза и т.д. Измеренная с помощью созданной ими утилиты FAHBench производительность вычислений с одинарной и двойной точностью показана на диаграмме. К сожалению на виртуальной машине UltraVDS утилита выдала ошибку.

    Дальше приведу сравнение результатов вычислений для метода моделирования dhfr-implicit.

    SiSoftware Sandra 20/20

    Пакет Sandra Lite отлично подходит для оценки вычислительных возможностей виртуальных видеоадаптеров различных хостеров. Утилита содержит наборы эталонных вычислительных тестов общего назначения (GPGPU) и поддерживает OpenCL, DirectCompute и CUDA. Для начала была сделана общая оценка разных vGPU. Диаграмма показывает сводный результат, более подробные данные для виртуальных серверов 1Gb.ru, GPUcloud (CUDA) и RuVDS доступны на сайте разработчика бенчмарка.

    С «длинным» тестом Sandra тоже были проблемы. Для VPS провайдера GPUcloud не получилось провести общую оценку с использованием OpenCL. При выборе соответствующей опции утилита все равно работала через CUDA. Не прошел этот тест и для машины UltraVDS: бенчмарк замер на 86%, пытаясь определить латентность памяти.

    В общем пакете тестов нельзя увидеть показатели с достаточной степенью детализации или проделать вычисления с высокой точностью. Пришлось провести несколько отдельных испытаний, начиная с определения пиковой производительности видеоадаптера с помощью набора простых математических расчетов с использованием OpenCL и (если это возможно) CUDA. Здесь также отражен только общий показатель, а детализированные результаты для VPS от 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS доступны на сайте.

    Для сравнения скорости кодирования и декодирования данных в Sandra есть набор криптографических тестов. На сайте доступны подробные результаты для 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS.

    Параллельные финансовые расчеты требуют поддерживающего вычисления с двойной точностью адаптера. Это еще одна важная сфера применения vGPU. На сайте доступны подробные результаты для 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS.

    Sandra 20/20 позволяет протестировать возможности использования vGPU для научных расчетов с высокой точностью: умножения матриц, быстрого преобразования Фурье и т.д. На сайте доступны подробные результаты для 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS.

    Напоследок был проведен тест возможностей vGPU по обработке изображений. На сайте доступны подробные результаты для 1Gb.ru, GPUcloud (OpenCL и CUDA), RuVDS и UltraVDS.

    Выводы

    Место Хостер Поддержка OpenCL Поддержка CUDA Высокая производительность по GeekBench 5 Высокая производительность по FAHBench Высокая производительность по Sandra 20/20 Низкая цена
    I RuVDS + + + + +
    II 1Gb.ru + + + + +
    III GPUcloud + + + + +
    IV UltraVDS + +

    У меня были определенные сомнения по поводу победителя, но обзор посвящен бюджетным VPS с vGPU, а виртуальная машина RuVDS стоит почти вдвое дешевле ближайшего конкурента и более чем вчетверо — самого дорогого предложения из рассмотренных. Второе и третье место тоже было непросто поделить, но и здесь цена перевесила прочие факторы.

    В результате тестирования выяснилось, что vGPU начального уровня стоят не так дорого и пользоваться ими для решения вычислительных задач уже можно. Конечно по синтетическим тестам сложно предсказать, как поведет себя машина под реальной нагрузкой, к тому же от соседей по физическому хосту напрямую зависит возможность выделения ресурсов — делайте на это скидку. Если же вы найдете на просторах рунета другие бюджетные VPS с vGPU, не сочтите за труд написать о них в комментариях.

    Источник

    Adblock
    detector