LINUX.ORG.RU

История изменений

Исправление mittorn, (текущая версия) :

может время иксов и ушло, но время wayland точно ещё не пришло и не придёт в близжайшем обозримом будущем. Я серьёзно его могу рассматривать только в качестве протокола для отрисовки приложений в VR. И то с этим даже сейчас xcomposite справляется.
Что должно появиться в мире wayland, чтобы я считал его альтернеативой иксам и вряд ли появится в близжайшее время:
1. Протокол отрисовки. Чтобы я мог в wayland рисовать в приложении что-либо средствами wayland, а не opengl/vulkan, либо на cpu как сейчас. Без этого я даже смысла портировать тулкиты на wayland с иксов не вижу, т.к порт априори получится хуже оригинала - либо прибит к 3д ускорителю, либо рисует всё на CPU.
2. Единая реализация композитора, желательно в виде библиотеки со стандартным API. Xorg своего рода фреймворк, реализующий и Xorg и Xwayland и Xephyr и Xnest. Не обязательно везде одна, но какая-то, которая будет являться официальной и использоваться в большинстве DE. wlroots близок к этому, но вечные ломки API и кривое API всё портит. Да и kwin/mutter наверно популярнее даже.
3. Реализация 2d ускорения. В xorg есть sna/uxa/exa и куча вендорских методов ускорения отрисовки 2d помиммо glamor. Вместе с первым пунктом это позволит эффективно использовать оборудование, а не грузить opengl по любой мелочи. Да и большинство 2д ускорителей нельзя было бы просто так дать любому пользовательскому приложению из-за отстуствия контроля доступа. Этим должен графический сервер заниматься, контроллируя доступ.
Так же это всё позволяет выводить opengl/vulkan/dri3 текстуры окон без композитинга как такового, если есть аппаратная реализация. Конечно в том же amdgpu это всё не используется, но это не отменяет других gpu. Но там, где есть 2д ускоритель, скорее всего без изменения ключевых решений, принятых в wayland его полноценно использовать нельзя. А 2d блиттинг будет куда быстрее и энергоэффективнее, чем запуск полноценного рендеринга там, где он есть
4. Сетевая прозрачность. Waypipe можете себе в хоть в задний pipe засунуть, к сетевой прозрачности он имеет такое же отношение как и vnc. Сетевая прозрачность может быть реализована при наличии пункта 1, сетевую прозрачность можно было бы реализовать поверх какого-нибудь virtio-gpu, если загнать его в сетевую абстракцию, либо же для glcore/webgl через virglrenderer, а гонять уже отрисованные поверхности - это просто vnc на стеройдах. Да, работает. Может даже намного лучше реальной сетевой прозрачности. Только вот на сервере без GPU уже всё на cpu рисует и жрёт кучу ресурсов. И aiglx из иксов в текущем виде тоже давно нужно выкинуть, gl1.4 мало кому нужен, зато webgl и gl core без когерентных буфферов и MapBuffer прекрасно ляжет на сетевую модель, а virglrenderer может работать по сети. Но конечно же никто просто не хочет это всё реализовывать

Исправление mittorn, :

может время иксов и ушло, но время wayland точно ещё не пришло и не придёт в близжайшем обозримом будущем. Я серьёзно его могу рассматривать только в качестве протокола для отрисовки приложений в VR. И то с этим даже сейчас xcomposite справляется.
Что должно появиться в мире wayland, чтобы я считал его альтернеативой иксам и вряд ли появится в близжайшее время:
1. Протокол отрисовки. Чтобы я мог в wayland рисовать в приложении что-либо средствами wayland, а не opengl/vulkan, либо на cpu как сейчас
2. Единая реализация композитора, желательно в виде библиотеки со стандартным API. Xorg своего рода фреймворк, реализующий и Xorg и Xwayland и Xephyr и Xnest. Не обязательно везде одна, но какая-то, которая будет являться официальной и использоваться в большинстве DE. wlroots близок к этому, но вечные ломки API и кривое API всё портит. Да и kwin/mutter наверно популярнее даже.
3. Реализация 2d ускорения. В xorg есть sna/uxa/exa и куча вендорских методов ускорения отрисовки 2d помиммо glamor. Вместе с первым пунктом это позволит эффективно использовать оборудование, а не грузить opengl по любой мелочи. Да и большинство 2д ускорителей нельзя было бы просто так дать любому пользовательскому приложению из-за отстуствия контроля доступа. Этим должен графический сервер заниматься, контроллируя доступ.
Так же это всё позволяет выводить opengl/vulkan/dri3 текстуры окон без композитинга как такового, если есть аппаратная реализация. Конечно в том же amdgpu это всё не используется, но это не отменяет других gpu.
4. Сетевая прозрачность. Waypipe можете себе в хоть в задний pipe засунуть, к сетевой прозрачности он имеет такое же отношение как и vnc. Сетевая прозрачность может быть реализована при наличии пункта 1, сетевую прозрачность можно было бы реализовать поверх какого-нибудь virtio-gpu, если загнать его в сетевую абстракцию, либо же для glcore/webgl через virglrenderer, а гонять уже отрисованные поверхности - это просто vnc на стеройдах. Да, работает. Может даже намного лучше реальной сетевой прозрачности. Только вот на сервере без GPU уже всё на cpu рисует и жрёт кучу ресурсов.

Исправление mittorn, :

может время иксов и ушло, но время wayland точно ещё не пришло и не придёт в близжайшем обозримом будущем. Я серьёзно его могу рассматривать только в качестве протокола для отрисовки приложений в VR. И то с этим даже сейчас xcomposite справляется.
Что должно появиться в мире wayland, чтобы я считал его альтернеативой иксам и вряд ли появится в близжайшее время:
1. Протокол отрисовки. Чтобы я мог в wayland рисовать в приложении что-либо средствами wayland, а не opengl/vulkan, либо на cpu как сейчас
2. Единая реализация композитора, желательно в виде библиотеки со стандартным API. Xorg своего рода фреймворк, реализующий и Xorg и Xwayland и Xephyr и Xnest. Не обязательно везде одна, но какая-то, которая будет являться официальной и использоваться в большинстве DE. wlroots близок к этому, но вечные ломки API и кривое API всё портит. Да и kwin/mutter наверно популярнее даже.
3. Реализация 2d ускорения. В xorg есть sna/uxa/exa и куча вендорских методов ускорения отрисовки 2d помиммо glamor. Вместе с первым пунктом это позволит эффективно использовать оборудование, а не грузить opengl по любой мелочи. Да и большинство 2д ускорителей нельзя было бы просто так дать любому пользовательскому приложению из-за отстуствия контроля доступа. Этим должен графический сервер заниматься, контроллируя доступ.
Так же это всё позволяет выводить opengl/vulkan/dri3 текстуры окон без композитинга как такового, если есть аппаратная реализация. Конечно в том же amdgpu это всё не используется, но это не отменяет других gpu.
4. Сетевая прозрачность. Waypipe можете себе в хоть в задний pipe засунуть, к сетевой прозрачности он имеет такое же отношение как и vnc. Сетевая прозрачность может быть реализована при наличии пункта 1, сетевую прозрачность можно было бы реализовать поверх какого-нибудь virtio-gpu, если загнать его в сетевую абстракцию, либо же для glcore через virglrenderer, а гонять уже отрисованные поверхности - это просто vnc на стеройдах. Да, работает. Может даже намного лучше реальной сетевой прозрачности. Только вот на сервере без GPU уже всё на cpu рисует и жрёт кучу ресурсов.

Исправление mittorn, :

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

Исходная версия mittorn, :

может время иксов и ушло, но время wayland точно ещё не пришло и не придёт в близжайшем обозримом будущем