Virtual 3d

[vitus_wagner]

Технология виртуализации 3d-графики мало помалу пробивает себе путь.

Мы уже имеем Linux 4.4 (сегодня)
QEMU 2.5 rc0 (позавера)
и поддержку VirGL в Mesa (пока только в транке, не отрелизено).
Не хватает еще guest-драйвера для Windows, чтобы пускать 3d игры в kvm.

Я, правда еще не совсем понял, нужно ли для использования virtio-virgl драйвера в KVM иметь ядро 4.4 на хосте или драйвер в ядре нужен только в guest. Но, полагаю, что к тому времени как у меня дойдут руки с ним поиграться, появятся более-менее вменяемые howto по настройке.

Comments

[amarao-san.livejournal.com]

Это уютная сказочка. В настоящий момент линуксовые игрушки (в т.ч. от valve'а) показывают ощутимо худшую производительность, чем их виндузявые версии.

При этом у X'ов есть ряд родных проблем (тиринг, например, который невозможно побороть полностью), адская небезопасность приложений друг от друга и т.д.

[vitus_wagner]

Идея, что приложения надо защищать друг от друга, это самая большая диверсия которую сделал гугл за всю свою историю.

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

Я бы сказал что в X-ах механизмы взаимодействия между приложениями безобразно недоразвиты.

[beldmit.livejournal.com]

Почему Google?

И Qubes ты тоже считаешь добивающими идею универсального компьютера?

[vitus_wagner]

Потому что то что делает Apple, он делает в своем гетто, которое никогда не превысит 15% пользователей. Проблемы начинаются когда у Apple начинают заимствовать.

А у Qubes изолируются друг от друга не приложения, а активности пользователя, внутри каждой из которых пользователь комбинирует столько приложений, сколько ему надо.

Это куда более правильная модель разделения доступа к информации, хотя и, возможно, чуточку слишком сложная для понимания большинством пользователей.

[amarao-san.livejournal.com]

Ну, я бы частично с этим согласился, если бы часть приложений не исполняли бы постронний неизвестно кем написанный код (ака браузер с JS'ом). Реалии таковы, что мы это позволяем, а значит, не должно быть ситуации, чтобы приложение "под скринсейвером" могло читать ввод пароля в скринсейвере.

[vitus_wagner]

На уровне приложений это не разграничивается. Потому что пароль, дающий доступ к нашему банковскому счету мы вводим все равно в том же приложении - в браузере, при заходе на сайт интернет-банка.

Приложения просто абсолютно нелогичная единица разграничения полномочий.

Security Zones в интернет-эксплорере - и то куда более логичная система.

[amarao-san.livejournal.com]

Ну, чисто теоретически, я хотел бы (хотя бы на уровне приложений) разрешать/запрещать перехват ввода/вывода других приложений.

У меня steam работает в network namespace от пользователя steam. И всё хорошо - но каждая игрушка имеет доступ к всем X'ам. И меня это напрягает.

[tzirechnoy.livejournal.com]

Над этим, конечно, надо работать -- но по факту правильно заметили, что оно и в винде в большынстве случаев неработает.

[tzirechnoy.livejournal.com]

А вообще, конечно, скринсэйвер в многопользовательской ОС должэн вызывать экран выбора пользовательской сэссии с возможностью запустить новую... Потому рутовый экран, конечно, аналог *dm.

[vitus_wagner]

Ну вообще-то в gdm это уже сто лет как есть.
Проблема в том что перехват пароля к джире или клиент-банку вводимого в соседнем окне браузера - ничуть не лучше перехвата пароля к системе.

[amarao-san.livejournal.com]

С другой стороны меня lightdm'овский лок страшно бесит, потому что после лока компьютера все мои процессы оказываются приостановлены (включая ssh'и, которые начинают отвалиться по таймаутам).

[permea-kra.livejournal.com]

Это не сказочка. Тормоза там не в OpenGL API, а в иксах. Тормоза, разумеется, есть.

Плюс, еще, physX нет под линуксом.

[amarao-san.livejournal.com]

Если быть точным, основная претензия к opengl (помимо общего насчёт перегруженности расширениями) - в том, что там все операции глобальные, то есть нельзя легко оставить программу наедине со своим окном (в котором оно рисует используя локальный хэндлер), или организовать context-switching. Все переменные в opengl задают глобальный контекст, который никак не подразумевает переключение между рисующими конкурирующими приложениями

[vitus_wagner]

Вот надо посмотреть, как это решается в свежем virtio-gpu. Хотя конечно, есть проблема в том что виртуализация переферийных процессоров это вообще задача очень непростая. Не приспособлены кролики для лазания, а специализированные сопроцессоры ввода-вывода для разделения времени, пространства и чего угодно еще между параллельными задачами.

Это еще в VM370 проходили и кончили тем что стали каналы на CPU эмулировать.

[amarao-san.livejournal.com]

Ну, всё, кроме GPU и всякой экзотической перефирии довольно неплохо на x86 виртуализировано. Сеть/диск/CPU - так просто великолепно. А вот с GPU проблема как раз в том, что сама железка плохо готова к виртуализации, а уровнень интерпретации/трансляции/изоляции оказывается неприлично дорогим по ресурсам. Примерно на уровне эмуляции старого железа (e1000). Жить можно, пользоваться в продакшене - уже не очень.

[permea-kra.livejournal.com]

Я категорически возражаю.
opengl контекст является локальным для треда, даже в разных тредах он имеет право быть разным.

И да, это на самом деле НЕ минус, поскольку потенциально быстрее локальных операций.

[tzirechnoy.livejournal.com]

+1. Да, opengl завязан на сраный pthreads, но это работает.

[amarao-san.livejournal.com]

Но он не является локальным для экрана. То есть какая-то внешняя сущность не может сказать в любой момент времени "стоп, ща рисуем state для другого десктопа". Так, чтобы первая сущность, когда ей вернут управление, могла бы продолжить рисовать используя те же id.

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

[tzirechnoy.livejournal.com]

>(помимо общего насчёт перегруженности расширениями)

Да нет там особой перегружэнности. Вот то, что в CORE SPEC коммитят дебилы -- есть, а расшырения в общем понятны все ужэ по названиям.

[tzirechnoy.livejournal.com]

Тормоза, разумеется, выдуманы. Иногда имеющиеся -- объясняются отличиями в драйверах. Тормоза от иксов -- вообще сказочка, учитывая, что отрисовка ускоренного 3D в виндах и линуксе имеет практически одинаковый codepath.

[tzirechnoy.livejournal.com]

Тиринг выглядит достаточно мифической проблемы, поскольку я так и не смог увидеть нормальное объяснение, что это такое и как это заметить IRL.

С безопасностью друг от друга в винде и макоси -- не лучшэ.

[amarao-san.livejournal.com]

Ну, у меня на 27" в 2560x1440 в видео - всегда есть. Какие бы режимы я не включал и как бы я с этим не боролся. В играх чуть лучше, потому что там разрыв менее заметен, но в видео с 25 кадрами - прям пальцем ткнуть можно.

Насчёт безопасности - по моделе нет, на практике, для winlogon'а специальные костыли со специальным режимом ввода пароля.

[tzirechnoy.livejournal.com]

-vo gl и framesync пробовал? Это AMD или nvidia?

[amarao-san.livejournal.com]

nvidia. gl и gl2, разумеется, пробовал. framesync - это кто и что?

[tzirechnoy.livejournal.com]

Что-то я как ни смотрю на очередные тэсты phoronix -- так такой однозначной корреляцыи не заметил.

physX на нвидии, да, под виндой выигрывает. Но где тот physX, да и не везде nvidia.