#faq
Всех приветствую!
Буквально в ближайший понедельник, 26 октября, будет релиз обновления AntiDetect с новым графическим движком.
И для того, чтобы избежать лишних вопросов, хотелось бы немного внести ясность. Так что кому интересна матчасть, можете продолжать читать этот пост, а кому интересен лишь результат — наслаждайтесь выходными днями, и уже в понедельник сможете скачать новую версию софта.
Итак, есть несколько различных методик ускорения графики в виртуальных машинах.
Первая методика — использование виртуальной видеокарты, как это реализовано, например, в VirtualBox, VMware, Proxmox и других системах виртуализации.
В зависимости от конкретной реализации такие виртуальные видеоадаптеры могут использовать разные версии модели графических драйверов WDDM, в том числе более старые, например WDDM 1.3.
Если мы условно возьмём возможности полноценной графической подсистемы за эталонные 100%, то, по моей оценке, некоторые реализации виртуальных видеоадаптеров не обеспечивают даже 40% этих возможностей.
И я сейчас говорю не только про скорость, но и про графические возможности, совместимость и так далее.
Потому что шейдер, например, — это не просто какая-то цифра, а целая программа, выполняемая графическим процессором. И вот в виртуальных машинах, увы, хорошего качества реализации и совместимости добиться достаточно сложно.
При этом графическое ускорение виртуального видеоадаптера, по моим наблюдениям в определённых конфигурациях, может работать примерно на уровне 5–7% от производительности реальной видеокарты хоста.
Второй метод — Juice.
Под этим постом я сброшу ещё одно видео, которое ранее записывал касательно системы Juice для ускорения графики, а точнее — GPU over IP, то есть предоставления доступа к видеокарте по сети.
Недостаток такого метода заключается в том, что он ориентирован преимущественно на ускорение отдельных приложений, а не на полноценное предоставление видеокарты всей системе.
То есть вы можете заставить работать с такой видеокартой, например, игру, а вот с браузером Chrome или непосредственно самой системой всё уже значительно сложнее. И это действительно большой минус данного метода.
Но есть у него и довольно-таки большой плюс.
Плюс заключается в том, что данный метод позволяет при локальном подключении получить, по моим оценкам, где-то в районе 30% от производительности реальной GPU.
Есть ещё один, третий метод. Он называется PCI passthrough, а точнее — PCIe passthrough.
PCIe passthrough — это методика, которая применима не только к видеокартам, но и практически к любому совместимому PCIe-устройству.
То есть это прямой, монопольный проброс физического PCIe-устройства внутрь виртуальной машины.
Метод сам по себе заслуживает, конечно же, огромного внимания, но для задач нашего продукта я рассматриваю его скорее как лабораторное решение.
На практике в массовом продакшн-продукте данный метод применять крайне сложно. И я объясню почему.
Причин несколько.
Причина номер один — это нестабильность работы в неподдерживаемых конфигурациях.
То есть вы пробросите видеокарту, возможно, она у вас даже появится в виртуальной машине. Но, к сожалению, при обращении к некоторым неподдерживаемым функциям или при проблемах с драйвером можно легко получить BSOD внутри виртуальной машины.
Недостаток номер два — это необходимость выделять отдельную физическую видеокарту для виртуальной машины. При этом для нормальной работы хостовой системы зачастую потребуется ещё один графический адаптер.
И, конечно же, вы не сможете одновременно пробросить одну и ту же физическую видеокарту в несколько виртуальных машин обычным методом PCIe passthrough, поскольку виртуальная машина будет монопольно владеть этим устройством.
То есть, иными словами, одна видеокарта — одна виртуальная машина.
Ну и недостаток номер три — это аппаратные требования и совместимость PCIe passthrough с материнскими платами.
А именно — необходима поддержка IOMMU, то есть Intel VT-d или AMD-Vi, а также соответствующая поддержка со стороны BIOS/UEFI и гипервизора.