LINUX.ORG.RU

Релиз Xorg 1.20

 , , ,


2

4

Спустя более полутора лет с момента прошлого значительного выпуска, состоялся релиз Xorg 1.20 ― реализации протокола X11, являющегося основной для подавляющего большинства графических окружений и оконных менеджеров.

В новом выпуске:

  • Реализована поддержка библиотеки GLVND (GL Vendor Neutral Dispatcher), работающей на стороне сервера (GLXVND), что позволяет осуществить автоматическое переключение видеокарт на системах с гибридной графикой (например Nvidia Optimus) путём использования на одной системе одновременно и свободного драйвера из Mesa, и проприетарного (Nvidia). Ранее GLVND был реализован лишь с клиентской стороны, и позволял держать на одной системе две разные libgl1.so
  • Компанией Nvidia предложен новый алгоритм определения устройств, сильно упрощающий их автонастройку и избавляющий от дублирования одного и того же драйвера при использовании нескольких одинаковых устройств, например GPU, в отличии от прежнего алгоритма, сильно переполняющего список устройств. Патч находился на обсуждении 2 года;
  • Обеспечена поддержка технологии DRM Leases, разработанной Китом Паккардом совместно с компанией Valve, в компоненте RandR 1.6. Данная технология необходима для работы шлемов виртуальной реальности, и решает такие проблемы как определение шлема как обычного монитора, а также убирает компоненты графического окружения на пути вывода графики на шлем (в составе SteamVR уже присутствует специальный композитор, построенный на Vulkan и занимающийся компоновкой изображения на VR-устройстве). Вывод осуществляется с использованием штатных технологий ядра Linux, таких как DRM/KMS. Части DRM Leases уже реализованы для ядра Linux (4.15+) и libdrm, также тестируется набор патчей для Mesa (Intel ANV и Radeon RADV) и на обсуждении находится расширение протокола Wayland;
  • Порция значительных улучшений в драйвере Modesetting: реализована поддержка расширений DRI3 v1.1 и v1.2, обеспечена поддержка атомарного переключения видеорежимов, серьёзно улучшена поддержка 2D ускорения в GLAMOR; обеспечена поддержка DRM модификаторов, позволяющих оптимизировать пропускную способность видеопамяти благодаря сжатию и мозаичному размещению плоскостей. Поддержка обеспечена в том числе в драйверах Intel (i965 и ANV), а также в GNOME Mutter, KDE Plasma 5 (патчи пока не в основной ветке), wlroots и Weston, однако для стандартизации размера буферов в драйверах и их распределения будет использоваться предложенная компанией Nvidia реализация «Unix Device Memory Allocator»; обеспечена поддержка 30-ти битной глубины цвета (DeepColor), делающей возможным использование современных HDR-телевизоров и мониторов;
  • В список extramodes-видеорежимов X-сервера добавлены разрешения до 15360 x 8640 (16:9) и до 2560x1600 (16:10). Отныне для монитора с любым разрешением экрана будет сразу выставляться наиболее подходящее на уровне Xorg;
  • Порция значительных улучшений в компоненте Xwayland: обеспечена поддержка протоколов xdg-output, xwayland-keyboard-grub, tablet и linux-dmabuf, необходимых для поддержки дробного масштабирования, захвата клавиатурного ввода (необходимо для работы виртуальных машин), поддержки графических планшетов и поддержки DRM модификаторов через DMA-BUF соответственно; обеспечена поддержка нескольких буферов изображений; решены проблемы с тирингом, благодаря использованию метода Page Flipping, реализованного в расширении Present. Данный метод позволяет использовать два видеобуфера по очереди (пока один заполняется, другой выводит изображение на экран) с привязкой к отдельным окнам; добавлена поддержка технологии EGLStreams, на которой построена реализация Wayland в проприетарном драйвере Nvidia, что отныне позволяет запускать GLX-приложения в Xwayland, работающем в Wayland-окружении проприетарного драйвера Nvidia (требуется патченый Weston или GNOME Shell 3.24+ собранный с поддержкой egl-device, а также ручное включение DRM/KMS в драйвере);
  • Обеспечена начальная поддержка сборочной системы Meson

Пользователям видеокарт Nvidia необходимо установить драйвер 396.24, в котором обеспечена поддержка нового Xorg

>>> Подробности

что за расширение present и какие именно проблемы с тирингом были решены? его больше нет? каким боком к тирингу мерцание?

anonymous ()
Ответ на: комментарий от te111011010

Так оптимус заработал как на шindows, или всё ещё пока нет?

Как только Nvidia добавит поддержку GLXVND в свой драйвер (а её инженеры создавали GLXVND совместно с Red Hat) - то да, будет переключаться автоматом, без всяких Bumblebee и прочих костылей.

Sunderland93 ★★★★★ ()
Ответ на: комментарий от te111011010

Так оптимус заработал как на шindows, или всё ещё пока нет?

На шиндовсе он работал и продолжает работать по точно такой же схеме, как в bumblebee - косо, криво и через жопу. Разница только в том, что в шиндовсе это происходит без участия VirtualGL, так как невидия там свои костыли наворотила.

Quasar ★★★★★ ()
Ответ на: комментарий от te111011010

Соединить два видеочипа и задействовать при слабых нагрузках один, а при сильных — сразу два.

Это уже сделано в последней версии спецификации Vulkan и называется это MGPU.

Quasar ★★★★★ ()
Ответ на: комментарий от anonymous

что за расширение present

https://cgit.freedesktop.org/xorg/proto/presentproto/tree/presentproto.txt очередной костыль в иксах, в общем.

какие именно проблемы с тирингом были решены? его больше нет?

Вот этого сказать не могу, не проверял. Взял из описания патча.

каким боком к тирингу мерцание?

Тут я напутал немного, в оригинале имеется ввиду page flipping, я не знаю как правильно на русский перевести этот термин

Sunderland93 ★★★★★ ()
Последнее исправление: Sunderland93 (всего исправлений: 1)
Ответ на: комментарий от ivanlex

В Fedora 28 точно войдёт, она на следующей неделе выйдет. В Debian Sid тоже, но наверно спустя пару месяцев после релиза. Ну и в Арчи всякие, само собой. А там уже в осеннюю Убунту и так далее.

Sunderland93 ★★★★★ ()
Ответ на: комментарий от te111011010

а в этом смысле, это есть в вулкане и ДХ12 там можно писать код который будет распределятся по всем ресурсам, но это требует программной поддержки в каждом приложении и для некоторых задач не даёт прироста производительности.

а сли это намного более примитивная и ограниченная технология которая так-же требует программной поддержки и как показала практика довольно редко даёт прирост без потери стабильности.

Thero ★★★★★ ()
Ответ на: комментарий от Sunderland93

Так оптимус заработал как на шindows, или всё ещё пока нет?

Как только Nvidia добавит поддержку GLXVND в свой драйвер (а её инженеры создавали GLXVND совместно с Red Hat) - то да, будет переключаться автоматом, без всяких Bumblebee и прочих костылей.

В Fedora уже работает: https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/

anonymous ()
Ответ на: комментарий от mandala

Ну и кто там мечтает о невидии с вяленым? лет через 5 ждите, может быть.

Ты так говоришь, как будто его засадили уже...

А так ни в chromium, ни в Firefox 🦊, ни в Steam... Это пока сидеть с прокладками и багами...

fornlr ★★★★★ ()

А этот самый PRIME умеет одновременно использовать две карточки (гибридная графика) или только одну использует при запуске через DRI_PRIME=1?

anonymous ()

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

ты так говоришь, как будто такому положению что-то объективно угрожает в ближайшие лет 5-7.

Bruce_Lee ★★ ()
Ответ на: комментарий от bodqhrohro_promo

Всё зависит от того, что это за проекты. Если проект предполагает, что он состоит из кучи опциональных частей, которые юзер по желанию включает и выключает (или перед сборкой нужно определить какие библиотеки есть в системе и отключить те модули, для которых нет библиотек в системе), или, например, он портабельный между кучей разных операционок и на каждой платформе задействуется специфичный для неё код, то, да, plain Makefile'ов может быть очень недостаточно.

Но, если проект не является модульным и платформозависимым (или рассчитан только на одну единственную платформу), а его Makefile'ы просто описывают железно определённую последовательность сборки, которая просто работает, то этих Makefile'ов более чем достаточно самих по себе.

Как вариант в отдельных проектах, например, используются пучки разных Makefile'ов для разных платформ, и нужно либо скопировать нужный архитектурнозависимый в какой-нибудь дополнительный Makefile.arch, или выбрать нужный через опцию -f.

saahriktu ★★★★★ ()