Робота над удосконаленнями XWayland продовжується і розробниками вони дали знати Нещодавно що Xwayland був модифікований, щоб дозволити прискорення представництва апаратним забезпеченням в системи з фірмовими графічними драйверами від NVIDIA.
Для тих, хто не знає XWayland, вони повинні це знати це X-сервер, який працює під управлінням Wayland і забезпечує зворотну сумісність для застарілих програм X11, що забезпечує організацію запуску програм X11, що працюють на сервері X.Org, у середовищах на базі Wayland.
Як багато хто з вас знатиме, Wayland - це повна віконна система для себе. Зі свого боку, сервер Xorg може бути модифікований для використання пристроїв введення Wayland для введення та пересилання кореневого вікна або окремих вікон верхнього рівня як поверхонь Wayland.
Компонент розробляється як частина основної кодової бази X.Org і раніше він був випущений разом із сервером X.Org, але через затримку сервера X.Org та невизначеність з випуском 1.21 в контексті постійного активного розвитку XWayland, було вирішено відокремити XWayland та опублікувати накопичені зміни у вигляді окремого пакету.
Судячи з тестування розробників, після увімкнення цих виправлень продуктивність OpenGL та Vulkan у додатках X, запущених із XWayland, майже така ж, як під контролем звичайного сервера X.
Зміни підготував працівник NVIDIA, У власному драйвері NVIDIA підтримка компонентів, необхідних для використання прискорення в Xwayland, з’явиться в майбутньому випуску, імовірно, у відділенні 470.x.
Ці два патчі призначені для супроводу майбутньої підтримки власного драйвера NVIDIA для апаратно прискореного рендерингу GL та Vulkan із Xwayland. Вони не повинні заважати поточній підтримці GL на основі swrast, тому, як тільки зміни на стороні водія вийдуть за межі, все повинно почати працювати. Однак я хотів би спершу подати на розгляд ці наші, на випадок, якщо хтось має якісь суттєві занепокоєння щодо загального підходу. Докладніше про реалізацію див. У повідомленнях-підтвердженнях.
Продуктивність повинна бути приблизно на рівні з рідним X11 на основі бенчмаркінгу, який я робив. Доситлива додаткова копія все ще потрібна для презентації вікон, але вплив, схоже, не значний, і повноекранні програми не матимуть цієї проблеми (до тих пір, поки композитор підтримує необхідний інтерфейс zwp_linux_dmabuf_v1).
Також, можна спостерігати різні інші події, пов’язані зі стеком графіки Linux, оскільки Розробники Wayland планують перейменувати головну гілку у всіх їх сховищах від "господаря" до "головного", оскільки останнім часом слово "господар" вважається політично некоректним, воно нагадує рабство, і деякі члени спільноти сприймають його як образливий. У свою чергу, спільнота freedesktop.org вирішила використовувати для основних сховищ `` main '' замість `` master '' для нових проектів.
Цікаво, теж цій ідеї були противники. Зокрема Ян Енгельгардт, який підтримує понад 500 пакунків на openSUSE, Аргументи GitHub та SFC щодо заміни "master" на "main" назвав лицемірством та подвійними стандартами. Він запропонував залишити речі такими, якими вони були, і зосередитись на постійному розвитку, а не створювати безлад при зміні назв.
За словами Яна, для тих, хто не може прийняти термін "господар", вони можуть просто гарантувати роботу двох відділень з однаковим станом зобов'язань і робити це, не порушуючи встановленої форми.
Ще одна зміна - в lavapipe контролера Mesa який розроблений для програмного рендерингу та використовує LLVM для генерації коду, реалізований графічний API підтримки Vulkan 1.1 та деякі особливості специфікації Vulkan 1.2 (раніше lavapipe повністю сумісний лише з OpenGL). контролер успішно проходить всі тести, що охоплюють нові можливості Vulkan 1.1, але поки що він не проходить ті самі тести для Vulkan 1.0, перешкоджаючи його офіційній сертифікації для підтримки Vulkan.
Фуенте: https://gitlab.freedesktop.org/