Разработчики гипервизора Xen представили (http://blog.xen.org/index.php/2014/03/11/xen-graphics-virtua.../) развиваемый компанией Intel проект XenGT, нацеленный на создание решения для полной виртуализации GPU и обеспечения работы прослойки для взаимодействия из гостевых систем с реальными GPU Intel. XenGT подразумевает поддержание отдельных виртуальных GPU для каждого виртуального окружения, за которыми закрепляется часть критичных для обеспечения высокой производительности ресурсов реального GPU.Возможность использования обычных нативных видеодрайверов внутри виртуальных окружений без вмешательства гипервизора в областях, важных для достижения высокой производительности, обеспечивает оптимальное соотношение между функциональностью, производительностью и совместным использованием ресурсов. Таким образом XenGT приближает производительность графической подсистемы к конфигурациям с полным пробросом доступа к GPU, предоставляя при этом возможность совместного использования GPU между виртуальными машинами, без применения полной эмуляции или трансляции API DirectX/OpenGL. Несмотря на то, что в настоящее время в XenGT поддерживается только Xen и графическая подсистема процессоров Intel, отмечается что базовая логика является универсальной и может легко быть портирована для других систем виртуализации.
Для организации работы виртуальных GPU на стороне хост-системы (dom0) запускается специальный драйвер vgt (https://github.com/01org/XenGT-Preview), который берёт на себя функции планировщика, координирующего совместный доступ и распределение ресурсов реального GPU между виртуальными машинами. Ресурсы GPU логически разделяются на две категории: критичные для обеспечения высокой производительности (работа с видеопамятью и буферами команд в памяти) и все остальные (MMIO/PIO, регистры конфигурации PCI, таблицы GTT и пополнение очереди команд GPU). Для первой категории обеспечивается прямой проброс к реальному GPU, для второй выполняется диспетчеризация через промежуточную прослойку, на стороне которой выполняется разделение доступа и эмуляция виртуальных GPU.
<center><a href="http://blog.xen.org/wp-content/uploads/2014/03/arch_of_xengt... src="http://www.opennet.me/opennews/pics_base/0_1395389600.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>URL: http://blog.xen.org/index.php/2014/03/11/xen-graphics-virtua.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39370
Неплохо, как для тех, кому нужны GPU-специфичные вычисления, так и для геймеров (можно не покупать вторую видяху, чтобы пробрасывать ее в виртуалку).
Надеюсь, скоро появится поддержка и для радеонов.
Мьсё, вы невнимательны. Данный "драйвер" призван работать только с видеокартами от Intel. По мне, не особо игровые видеокарты. Так же не указано, какие именно решения\модели будут поддерживаться данным драйвером (Может только Iris Pro и выше, а HD2500+ идут лесом?)
Можно надеяться что по аналогии с Intel сообщество сможет запилить для AMD и nVidia.
Я про AMD и говорил. А нвидия в очередной раз показывает средний палец своим покупателям.
ты главное почаще повторяй себе это.
Вы так обижаетесь, как будто это я вам показываю средний палец, а не ваша любимая.
> показывает средний палец своим покупателям.Ну почему, есть же NVIDIA GRID. И вроде бы как даже в XenServer поддерживается. И интересно все это продавать в VDI для CAD/CAM cистем.
> Ну почему, есть же NVIDIA GRID. И вроде бы как даже в XenServer поддерживается.И почем стоит?
E nVidia уже тоже есть решение на K1 и K2 - но только для VmWare
Тссс, не развеивай их мечты! ОпинСоурсы же думают, что самое передовое появляется у них.
"отмечается что базовая логика является универсальной"
Значит, и как основа для других видеоархитектур подойдёт.
Подойти-то подойдет, но реализовать получится только для тех, у которых открыты спеки.
Помимо интела, это амд. Невидия в пролете (вряд ли ее штатные индусы получат задание этим заниматься, а реверс-инжиниринг, как мы видим на примере nouveau, дает не лучшие результаты).
> Подойти-то подойдет, но реализовать получится только для тех, у которых открыты спеки.
> Помимо интела, это амд. Невидия в пролете (вряд ли ее штатные индусы
> получат задание этим заниматься, а реверс-инжиниринг, как мы видим на примере
> nouveau, дает не лучшие результаты).В принципе, особых преимуществ по сравнению с использованием видео без xen здесь практически нет. Хотя эффективность работы с видео ОС, работающих в виртуальных машинах xen, может возрасти.
Мьсё, вы невнимательны.
> базовая логика является универсальной и может легко быть портирована для других систем виртуализации
Разработчики Xen сделали то, что нужно мне, уже давно. Это проброс видеокарты. Подключаю монитор к интегрированной видеокарте, запускаю скрипт из двух команд для Xen, чтобы он зарезервировал вторую видеокарту, и система её не задействовала внезапно. Затем стартую виртуальную машину и играю в Direct3D 11 игры в Linux.
Зачем такие мучения? Неужели нельзя просто взять винду, без всяких виртуалок? Или вам принципиально, чтобы в системе обязательно был процесс "SystemD"?
Не знаю, чем он руководствуется. Я в игрушки не играю, но если таки нужно что-то не запускаемое в wine, то я предпочитаю, чтобы:
во-первых, Венда была отгорожена от инета настоящим файерволом, а не блобьём, незнамо что там делающим;
во-вторых, чтобы можно было оперативно переключиться и, например, почитать почту, обменяться сообщениями XMPP и т.д. (Мы ж всё же не во времена однозадачной DOS живём). А работать с личной информацией я, как-то, предпочитаю не в проприетарной ОС.
опровержение аргумента 1:> а не блобьём, незнамо что там делающим
Безопасность открытого кода, который вы лично не проверили, равна безопасности закрытого.
опровержение аргумента 2:
> я предпочитаю
Вопрос личных предпочтений не подлежит осуждению. Лишь замечу, что организованная вами схема работы черезшигоринская.
Стаканчик уже остаканился
Ну так пятница же!
> Безопасность открытого кода, который вы лично не проверили, равна безопасности закрытого.Неа. Выложить закрытый блоб с бэкдорами или открытый код с бэкдорами - это два совершенно разных уровня рисков.
Примерно как ходить с наркотой по трущобам, куда полицейские боятся соваться vs ходить с ней по улице, на которой через шаг стоят крайне подозрительные полицаи.
Типичное заблуждение.В открытом коде, который будут видеть множество людей, вредоносный код будет более изощерённо спрятан, что снизит его шансы на обнаружение.
"На открытом месте прятаться лучше, чем в лесу, потому что гладиолус"Странная у вас, вантузоидов, логика. Даже у блондинок в рассуждениях здравого смысла больше.
Вообще, он прав. Закрытый код - необходимость казачков. Открытый - отослал набор патчей и всё. Никто ни о чём не догадался.
Да-да, на деревню, дедушке.
И ейной мордой в мою тыкал.Интересно, вот такой бред на опеннете нести — это от недостатка общения или ещё что…
> Вообще, он прав. Закрытый код - необходимость казачков. Открытый - отослал набор
> патчей и всё. Никто ни о чём не догадался.Ага, ага. Там "на приеме" сидят ну совсем тупые и без проверки прям так все подозрительные патчи в master и пихают...
Есть такая штука - человеческий фактор. Бэкдоры пихать никто не стал бы, а вот уязвимость, которую можно было бы проэксплуатировать - почему бы и нет? Штук 10 патчей, которые в большинстве своём будут работать, но каждый будет содержать незаметную ошибку. Пусть даже штук 7 из них обранужат, укажут на недочёт, будут ещё патчи. А если от разных людей, то и подозрений никаких не возникнет. Но для этого должен быть ооочень грамотный человек по части компьютерной безопасности, который бы всю эту схему продумал.
>Пусть даже штук 7 из них обранужат, укажут на недочёт, будут ещё патчи.До самого-то дошло хоть, в пользу чего это утверждение?
В пользу того, что разработчики ОпенСурс - люди грамотные. И?
Грамотность - это умение читать и писать. У вас были сомнения что разрабы грамотны?
> Вообще, он прав.Вообще-то, он пишет фигню, и сам это понимает. Но работа есть работа.
> Закрытый код - необходимость казачков.
Зачем? Сам вендор и будет эксплуатировать. Сочтет нецелесообразным - продаст тем, кому этим заниматься сподручнее.
> Открытый - отослал набор патчей и всё.
Все это замечательно, но разбивается об один маленький нюанс: в открытом сообществе все друг друга более или менее знают.
Про открытые сообщества - правда. Но есть достаточно большие сообщества. Догадываюсь, что люди там кучкуются. А присылать патчи могут в принципе кто угодно. Если кто-то будет слать грамотные патчи на протяжении длительного времени, положим пару месяцев, он сможет среди них отослать и те, которые необходимо. Если таких людей много, положим человек 10, вероятность создать полноценную уязвимость в проекте достаточно велика. Согласен, это муторно, долго, нужны грамотные люди. Но сколько у нас стран, сколько спецслужб? Есть вероятность что кто-нибудь, да делает так.
> Согласен, это муторно, долго, нужны грамотные люди.Вот мы и пришли к тому, с чего начали: договориться с проприетарным вендором на порядок проще :-P
А если фирма-разработчик находится в другой стране? Если она уже заключила договор с той страной? Сможет ли такой же договорчик с ней провернуть кто-либо ещё? Или потом исходная страна просто получит ешё один путь доступа в свой арсенал, а другая страна - заплатит за лишнюю дырку в своей защите? Больше чем уверен, что Сноуден сейчас продаёт довольно-таки много информации, которую можно использовать против США и не только.
Вы столько вопросов задали, а ответ на них один: it depends.Но даже с учетом всех этих заморочек, получается гораздо проще организации "фейкового сообщества", которое по факту может себе позволить только США.
Для проектов типа folding@home
Имеет смысл для крупных центров облачных вычислений, которые раздают виртуалочки. Дает возможность задействовать на таких виртуалках гпу для спецэфических задач.
Например, запустить там spellchecker какой-нибудь.
Кто уже смотрел? Производительность как?
