После шести месяцев разработки анонсирован (http://lists.x.org/archives/xorg-announce/2015-February/0025...) релиз X.Org Server 1.17. Новый выпуск примечателен (http://cgit.freedesktop.org/xorg/xserver/) интеграцией DDX-драйвера xf86-video-modesetting (http://cgit.freedesktop.org/xorg/xserver/commit/?id=35dc7c75...), проведением значительной чистки кодовой базы от устаревших компонентов и оптимизацией архитектуры 2D-ускорения GLAMOR (http://www.freedesktop.org/wiki/Software/Glamor).
Xf86-video-modesetting является универсальным DDX-драйвером, который можно сравнить с драйвером VESA, но работающим поверх интерфейса KMS. Драйвер xf86-video-modesetting можно использовать для любого оборудования, для которого имеется работающий на уровне ядра драйвер DRM/KMS, но отсутствует родной драйвер DDX. Для 2D-ускорения драйвером поддерживается архитектура GLAMOR, а для прямого обращения к видеоподсистеме интерфейс DRI2.
Другое значительное улучшение связано с проведением оптимизации производительности архитектуры 2D-ускорения GLAMOR (http://www.freedesktop.org/wiki/Software/Glamor), в которой для ускорения 2D-операций используется OpenGL и шейдеры. GLAMOR поддерживается в драйверах RadeonSI, Nouveau и Intel, и используется в XWayland, прослойке для выполнения немодифицированых приложений X11 в окружении на базе Wayland.URL: http://lists.x.org/archives/xorg-announce/2015-February/0025...
Новость: http://www.opennet.me/opennews/art.shtml?num=41612
> проведением значительной чистки кодовой базы от устаревших компонентов и оптимизацией архитектуры 2D-ускорения GLAMOR.всё правильно делают!
в будущем единственная цель XOrg -- будет работа внутри Wayland (на GLAMOR-бэкенде).
в связи с этим, подчищать код надо..
Вяленый только для домашнего пользования, и любителей *&(8buntu.
Нормальные системы делаются на Xorg который дает множество возможностей до которых Wayland далеко как .... (не ближе солнца).А новость хорошая, надо будет обновиться.
>дает множество возможностей до которых Wayland далеко какС этого места можно более подробно?
>С этого места можно более подробно?1. Запуск нескольких X-серверов, в том числе с разными wm.
2. ssh -X.
3. X-свойства окон/фреймов.
> 1. Запуск нескольких X-серверов,При том чаще всего надо лишь потому что нормальную мультисессионность при сколь-нибудь вменяемом разделении прав в иксах фиг получишь.
> в том числе с разными wm.
У этого есть какое-то практическое применение?
> 2. ssh -X.
Ну да, на серваке с гигабитным каналом и немеряным процом даже работает. Во всех остальных случаях - ну вы поняли.
> 3. X-свойства окон/фреймов.
Что - свойства?
Гонево. Работает всё отлично.
Я в армии кино проигрывал на целероне, а смотрел на иксах простого "пенька".
Сетевуха была коаксиальной.
> Гонево. Работает всё отлично.Правда, почему-то сами разработчики которые все это пилят - иного мнения на этот счет.
> Я в армии кино проигрывал на целероне,
> а смотрел на иксах простого "пенька".
> Сетевуха была коаксиальной.Это так, фигня по сравнению с подметанием ломом плаца.
>При том чаще всего надо лишь потому что нормальную мультисессионность при сколь-нибудь вменяемом разделении прав в иксах фиг получишь.Это смотря что понимать под мультсессионностью.
>У этого есть какое-то практическое применение?
Да. Например, полностью настроенный под себя тайловый wm и что-нибудь минималистичное.
>Ну да, на серваке с гигабитным каналом и немеряным процом даже работает. Во всех остальных случаях - ну вы поняли.
У меня работал через 100 мегабитный свитч. И через вай-фай — без понятия, сколько там, но не больше 54 в любом случае. Так что кое-кто уже приврал минимум в 10 раз, а то и в 20.
>Что - свойства?
То свойства. Информация о классе, имени, типе окна или фрейма. В вейланде с этим не очень, т.к. многое отдано на откуп клиентам.
> Это смотря что понимать под мультсессионностью.Возможность держать несколько сессий разных пользователей. С нормальным разделением прав и изоляцией, когда пользователи не смогут друг другу все и вся факапить.
> Да. Например, полностью настроенный под себя тайловый wm и что-нибудь минималистичное.
А несколько серверов при этом случайно не являются ли ужасным костылем? Зачем их должно висеть несколько, если по логике вещей?
> У меня работал через 100 мегабитный свитч. И через вай-фай — без
> понятия, сколько там, но не больше 54 в любом случае. Так
> что кое-кто уже приврал минимум в 10 раз, а то и в 20.В любом случае - без костылей оно нормально работает только в шустрой локалке, а если кто активно рисует графику (e.g. плеер) - там вообще ужас-ужас.
> То свойства. Информация о классе, имени, типе окна или фрейма. В вейланде
> с этим не очень, т.к. многое отдано на откуп клиентам.А в иксах клиенты не могут даже шапку окна как-то с пользой использовать. И современные клиенты одинфиг рендерят все на своей стороне, потому то иксы в этом плане "не очень". А потом бонусом оказывается что иксы "не очень" еще и для вывода этих зарендереных битмапов.
Зато там дофига уберсложного кода и 100500 костылей и подпорок где хоть как-то пытались привести эти древности в хоть какое-то соответствие с современными реалиями. Все это настолько ужас-ужас что многие заинтересованные в вяленде - разработчики xorg как раз.
>Возможность держать несколько сессий разных пользователей. С нормальным разделением прав и изоляцией, когда пользователи не смогут друг другу все и вся факапить.Лично мне не требовалось, мне требовалось два икс-сервера от разных пользователей — работало идеально.
>А несколько серверов при этом случайно не являются ли ужасным костылем? Зачем их должно висеть несколько, если по логике вещей?
fullscreen приложение и десктоп с возможностью почти мгновенного переключения туда и обратно, разными разрешениями и глубиной цвета.
>В любом случае - без костылей оно нормально работает только в шустрой локалке, а если кто активно рисует графику (e.g. плеер) - там вообще ужас-ужас.
Зато хотя бы работает: все эти vnc/rdp/teamviewer`ы уж всяко не быстрей, с их попытками протащить видеопоток с полным десктопом вместо одного-трёх окон.
>А в иксах клиенты не могут даже шапку окна как-то с пользой использовать.
С учётом того, что в тайловых wm ты этй самую шапку окна и не увидишь — нормальное решение.
>Зато там дофига уберсложного кода и 100500 костылей и подпорок где хоть как-то пытались привести эти древности в хоть какое-то соответствие с современными реалиями.
Если твой горячо любимый, но всё ещё непригодный к практическому использованию wayland допилят когда-нибудь хотя бы до половины функционала иксов, он также обрастёт костылями в два слоя. Даже больше — ибо он заведома планируется как урезок с весьма скудным набором возможностей.
> Лично мне не требовалось, мне требовалось два икс-сервера от разных пользователей —
> работало идеально.Нет такого юзкейса как "мне требуется два икс-сервера". Это квадратно-гнездовое мышление. Есть задачи типа "2 логин сессии для 2 разных юзерей". Но запуск под это 2 разныз серверов - в общем то костыль и затраты ресурсов на отдельные копии сервера. С фига ли они должны быть - вообще малопонятно.
> fullscreen приложение и десктоп с возможностью почти мгновенного переключения
> туда и обратно, разными разрешениями и глубиной цвета.В этой формулировке самой по себе не содержится никаких икс-серверов и прочего...
> Зато хотя бы работает: все эти vnc/rdp/teamviewer`ы уж всяко не быстрей, с
> их попытками протащить видеопоток с полным десктопом вместо одного-трёх окон.Да вот пролезает как-то. Даже чуть ли не по дилапу. Чего иксам ни разу не грозит. А валв как ни странно видеопотоком даже игры прокиывает. При этом относительно вменяемый бандвиз, в отличие от. За счет lossy сжатия потока.
> С учётом того, что в тайловых wm ты этй самую шапку
> окна и не увидишь — нормальное решение.Ну вот этому нормальному решению имхо суждено остаться у горстки маргиналов. А остальные его пошлют. И поддерживать это монстрило вы имхо будете сами.
> Если твой горячо любимый, но всё ещё непригодный к практическому использованию wayland
> допилят когда-нибудь хотя бы до половины функционала иксов,Вот кому надо этот функционал, тот пусть и пилит. А мне хватит быстрого отображения локальной графики и проброса видеопотока а-ля валв ремотно. В сто раз проще и не клинится даже на отрисовке очень интенсивно рисующих программ.
> он также обрастёт костылями в два слоя.
Но не настолько жестоко как иксы, потому что делалось с учетом современных реалий и запросв.
> Даже больше — ибо он заведома планируется
> как урезок с весьма скудным набором возможностей.Я лучше буду летать нормальным самолетом чем гибридом самолета, подводной лодки и комбайна.
Путаешь с MIR
> Вяленый только для домашнего пользования, и любителей *&(8buntu.Для планшетного. Но кодовую базу Хов он засрёт капитально, как правильно пишет предыдущий докладчик.
> Для планшетного. Но кодовую базу Хов он засрёт капитально, как правильно пишет
> предыдущий докладчик.Все несколько печальнее для старперов. Иксы не прочь послать в пешее большинство их разработчиков. И если вы не заметили идет плавная такая унификация с вялендом. Всякие там libinput и прочая.
В один прекрасный (или не очень) день вы получите замечательный шанс - лично впрячься в поддержку кодовой базы xorg. Ну или выкручивться как умеете.
Расскажите, а как на Wayland сделать аналог Xdmx?
> Расскажите, а как на Wayland сделать аналог Xdmx?расскажи с какой именно проблемой ты столкнулся(?), когда начал делать Wayland-Композитор с функционалом анологичному Xdmx..
Я подключаю провод от ноута от к рабочему компу. И теперь у меня иксы от рабочего компа рисуются на два монитора. Как это сделать, если иксов у меня нет, а есть вэйланд? Сейчас вообще сетевых мониторов много развелось, каждый планшет, считай что монитор.
А ты пробовал или только предполагаешь?
Я Xdmx пользуюсь. Про wayland ничего не знаю, кроме слухов, что с сетевой частью там всё плохо.
Так попробуй! Заодно расскажишь как на самом деле, а не по слухам;-)
Зачем пробовать, если меня пока устраивает то, что есть.
гламорненько
Теперь владельцам AMD Radeon нужно будет устанавливать LLVM для компиляции шейдеров, чтобы работало 2D-ускорение через OpenGL (Mesa). ;)
И что?
> И что?Балласт.
libLLVM-3.7.so.1 у меня весит 33.7 мб, проприентарный драйвер жирнее.
> libLLVM-3.7.so.1 у меня весит 33.7 мб, проприентарный драйвер жирнее.% pkg info -s nvidia-driver-346.35
nvidia-driver-346.35 207MiBДа, печалька. ;)
ftp://download.nvidia.com/XFree86/Linux-x86_64/346.35/NVIDIA-Linux-x86_64-346.35-no-compat32.run 38.8 MB
> NVIDIA-Linux-x86_64-346.35-no-compat32.run 38.8 MBА ничего что он сжатый? Там архив внутрях :)
> libLLVM-3.7.so.1 у меня весит 33.7 мб, проприентарный драйвер жирнее.А у меня ноут с интелом (sna) после полной загрузки (ядро+драйвера+Xorg+dwm+st+mc+conky) съедает 21.5MB. Но что то мне подсказывает, что "счастливое" будущее уже рядом.
> А у меня ноут с интелом (sna) после полной загрузки (ядро+драйвера+Xorg+dwm+st+mc+conky)
> съедает 21.5MB. Но что то мне подсказывает, что "счастливое" будущее уже рядом.Вы пользуетесь видеокартой на уровне VGA адаптера. А если рассмотреть ее как числокрушилку так 20 метров памяти для сборки кода на ходу - не так уж и много памяти по логике вещей...
> Вы пользуетесь видеокартой на уровне VGA адаптера. А если рассмотреть ее как
> числокрушилку так 20 метров памяти для сборки кода на ходу -
> не так уж и много памяти по логике вещей...Если уж продолжить логику далее, то есть оно должно эти лишние метры только на приложениях которые используют шейдеры или OpenCL. Да и то после компиляции шейдеров/OpenCL kernels желательно выкинуть ненужный хлам из памяти.
На данный же момент, любое OpenGL приложение тянет все в память.
> Балласт.Эк ты шланга полил... :)
Так радеоновский драйвер из месы и так требует llvm (gallium3d же)
> Так радеоновский драйвер из месы и так требует llvm (gallium3d же)Там зависимость была опциональная, ускорение 2D шло не через Mesa. А сейчас на RadeonSI в xorg-server-1.17 всё (2D и 3D) будет идти через Mesa (OpenGL). Так что кому плавную прокрутку в Firefox и кино смотреть == ставить LLVM, иначе будет полностью софтверный рендеринг силами CPU (как в vesa-драйвере). Всё это называется модным словом Glamor.
Сама идея glamor не плоха - исключить 2d блок и связанный с ним код. Должно стать проще и лучше.Но на практике есть нюансы. OpenGL стал достаточно жирным с приходом gallium (что скорее связанно не с самой архитектурой, а с более поздним временем ее реализации, когда об экономии памяти все резко забыли). Теперь же еще и llvm. В итоге простое OpenGL приложение типа шестеренок ест памяти как нормальное gtk приложение. Ситуацию могла бы спасти статическая линковка (с выбрасыванием всего неиспользуемого кода), но не смотря на то, что почти все при сборке mesa линкуется статически, на финальном этапе мы можем получить только so. Насколько я понимаю связанно это с желанием разработчиков менять рендеринг без повторной линковки.
С другой стороны llvm нужен не только для 3d, но и для OpenCL.
P.S. Если у кого есть опыт сборки/патчи статической mesa (r600) - поделитесь, буду очень признателен!
> Сама идея glamor не плоха - исключить 2d блок и связанный с
> ним код. Должно стать проще и лучше.Ну так амдшники и рассудили - нафига им кастомный акселереж 2D, если это все-равно кодить? Ну и сделали вот так. Так что DDX драйвер оформляет все как частный случай 3D и при случае даже не стесняется шейдерами отрисовать что надо. Поэтому для GCN амд не писали EXA или что там еще и сразу ориентировались на гламур. По состоянию на сейчас довольно неплохо работает, кстати.
И да, в современых GPU нет никакого особого хардвара для ускорения именно 2D.
> Теперь же еще и llvm.
В RadeonSI он и был всегда. Самопальный кодогенератор есть в R600, а для SI его никогда и не было.
> Ситуацию могла бы спасти статическая линковка (с выбрасыванием всего
> неиспользуемого кода),Еще не хватало. Так шаред либы висят одни на всю систему, а так каждая программа будет duplicate код переть. И в какой-то момент вгрузить ОДНУ копию shared lib будет дешевле по ресурсам чем куча duplicate кода.
А еще это довольно сложный код. В нем могут быть баги. Самого разного толка. Шаред либы можно по людски апдейтить. А с статикой - ну вы поняли.
> P.S. Если у кого есть опыт сборки/патчи статической mesa (r600) - поделитесь,
> буду очень признателен!Очень сомнительное начинание, имхо. Куча грабель на ровном месте будет. Разработчики MESA в здравом уме и такую шизу врядли будут рассматривать всерьез.
>> Ситуацию могла бы спасти статическая линковка (с выбрасыванием всего
>> неиспользуемого кода),
> Еще не хватало. Так шаред либы висят одни на всю систему, а
> так каждая программа будет duplicate код переть. И в какой-то момент
> вгрузить ОДНУ копию shared lib будет дешевле по ресурсам чем куча
> duplicate кода.Не все так просто.
1. Для простых приложений (без шейдеров) можно выкинуть большую часть (llvm занимает больше чем весь остальной DRI+OpenGL).
2. Сколько у вас запущено OpenGL приложений одновременно?
3. Для простого OpenGL приложения Pss (не разделяемая занятая память) составила 6.9MB. То есть описанная вами ситуация не наступит никогда.
> А еще это довольно сложный код. В нем могут быть баги. Самого
> разного толка. Шаред либы можно по людски апдейтить. А с статикой
> - ну вы поняли.1. Это забота маинтейнеров дистрибутива.
2. Многие проекты тянут библиотеки с собой.
3. Если баг будет в неиспользуемом коде - то обновлять ничего не нужно.
4. Если баг будет в inline функции (в *.h), то без пересборки приложения не обойтись.Да и в целом механизм разделяемых библиотек гораздо более сложный. Так же проблема с inline функциями - компилятор не может вставить функции, тело которых находится не в *.h файлах.
http://www.akkadia.org/drepper/no_static_linking.html
http://sta.li/faq> Разработчики MESA
> в здравом уме и такую шизу врядли будут рассматривать всерьез.А --enable-static в configure в mesa самозародился что-ли? :)
> 1. Для простых приложений (без шейдеров) можно выкинуть большую часть (llvm занимает
> больше чем весь остальной DRI+OpenGL).Есть вещи типа kmsconsole рисующие прямо через DRM+KMS. У них по идее зависимостей меньше.
> 2. Сколько у вас запущено OpenGL приложений одновременно?
Да хоть тот же браузер - запущен почти всегда и ему надо по сути весь GL ES. Потому что WebGL. А если DDX драйвер иксов намерен сбагривать все и вся как GLные сущности и шейдеры - вообще все что под иксами будет этим пользоваться, так что сэкономить не получится и все тут.
> 3. Для простого OpenGL приложения Pss (не разделяемая занятая память) составила 6.9MB.
> То есть описанная вами ситуация не наступит никогда.То-есть, элементарный запущенный браузер - реализует WebGL. Это почти весь GL ES, насколько я помню. Или иксы, которые в случае гламура все гонят как 3D примитивы. Там половина ускорений сделано через шейдеры, без генератора шейдеров - никуда.
> 1. Это забота маинтейнеров дистрибутива.
И они не будут дрюкаться с статичной линковкой. Им проще 1 пакет с либой заменять.
> 2. Многие проекты тянут библиотеки с собой.
Да, в основном проприетарные и клавшие фиг что случится с юзером в случае проблем секурити.
> 3. Если баг будет в неиспользуемом коде - то обновлять ничего не нyжно.
Только всем будет впадлу заниматься продвинутой аналитикой - у них на это ресурсов нет. На это просто забьют.
> 4. Если баг будет в inline функции (в *.h), то без пересборки приложения не обойтись.
В целом это хреновая практика и заявка на дофига лишней работы на ровном месте.
> А --enable-static в configure в mesa самозародился что-ли? :)
Если честно - не видел ни 1 живого пользователя этой фичи. Хотя если сильно хочется прострелить себе пятку, разумеется это можно. Но в общем случае - нафигнужно.
А так если хочется размер libllvm урезать - наверное можно отпилить всякие там х86 платформы, например :). Если это только как генератор шейдеров интересует. Хотя на лично мое мнение - амд напрасно эту либу схапали. Проблем с ней дофига а разбирается в ней целый один Tom Stellard.
> Есть вещи типа kmsconsole рисующие прямо через DRM+KMS. У них по идее
> зависимостей меньше.Увы, не намного. Основной вес - gallium+llvm. На их фоне DDX и прочим Xorg можно пренебречь.
>> 2. Сколько у вас запущено OpenGL приложений одновременно?
> Да хоть тот же браузер - запущен почти всегда и ему надо
> по сути весь GL ES. Потому что WebGL.Ну у меня например WebGL отключен ;)
> А если DDX
> драйвер иксов намерен сбагривать все и вся как GLные сущности и
> шейдеры - вообще все что под иксами будет этим пользоваться, так
> что сэкономить не получится и все тут.Смотря что и как он делает.
1. Зачем нужен llvm после компиляции шейдеров?
2. У OpenGL есть много всего (и llvm думаю тоже), что можно выкинуть при точно определенной задаче. Например у gallium тратится 1.3MB только на функции преобразовании типов (что угодно во что угодно), хотя в реальном приложении нужны 2-3 типа.
>> 3. Для простого OpenGL приложения Pss (не разделяемая занятая память) составила 6.9MB.
>> То есть описанная вами ситуация не наступит никогда.
> То-есть, элементарный запущенный браузер - реализует WebGL. Это почти весь GL ES,
> насколько я помню. Или иксы, которые в случае гламура все гонят
> как 3D примитивы. Там половина ускорений сделано через шейдеры, без генератора
> шейдеров - никуда.Вы не поняли. OpenGL приложение съест 7MB как минимум, даже если запустить десяток одинаковых приложений. Если бы работала статическая линковка - то простое приложение съело бы 1-2MB, даже если только оно одно использует OpenGL.
>> 1. Это забота маинтейнеров дистрибутива.
> И они не будут дрюкаться с статичной линковкой. Им проще 1 пакет
> с либой заменять.Не понял проблемы - неужели нельзя в 21 веке запустить скрипт, который пересоберет билиотеку и программы от нее зависящие?
>> 2. Многие проекты тянут библиотеки с собой.
> Да, в основном проприетарные и клавшие фиг что случится с юзером в
> случае проблем секурити.Например firefox и libreoffice :)
>> 3. Если баг будет в неиспользуемом коде - то обновлять ничего не нyжно.
> Только всем будет впадлу заниматься продвинутой аналитикой - у них на это
> ресурсов нет. На это просто забьют.Есть такая вероятность, но это не значит, что это хорошо. Так как проблема inline остается. Да и фикс в библиотеке может сломать приложение.
>> 4. Если баг будет в inline функции (в *.h), то без пересборки приложения не обойтись.
> В целом это хреновая практика и заявка на дофига лишней работы на
> ровном месте.Предлагаете забить на производительность и отказаться от inline?
>> А --enable-static в configure в mesa самозародился что-ли? :)
> Если честно - не видел ни 1 живого пользователя этой фичи.На данный момент - да, эта опция не может нормально собрать mesa, так как нужно переключать рендереинг без повторной линковки.
> Хотя
> если сильно хочется прострелить себе пятку, разумеется это можно. Но в
> общем случае - нафигнужно.То есть забиваем на потребление памяти и производительность в угоду ленивым маинтейнерам?
> А так если хочется размер libllvm урезать - наверное можно отпилить всякие
> там х86 платформы, например :). Если это только как генератор шейдеров
> интересует.Можно, но llvmpipe отвалится, да и все равно очень много выходит.
> Хотя на лично мое мнение - амд напрасно эту либу
> схапали. Проблем с ней дофига а разбирается в ней целый один
> Tom Stellard.Возможно. Не знаю на чем основан их закрытый OpenCL, но бажит он знатно и память ест гигабайтами. Надеюсь открытый лучше получится.
врянье. Во первых программный рендеринг работает быстрее чем гламур. Во вторых без гламура там ни 2д ускорение, ни 3д не работало никогда. (что не меняет того факта что там скорее не ускорение, а 2д замедление. Только 3д без этого замедления работать не будет)
> Во первых программный рендеринг работает быстрее чем гламур.Ага, щаз. Покажите бенчмарки? Вообще-то гламур нынче нехило оптимизнули и он по скорости не собирается продувать всяким там EXA и SNA.
> не меняет того факта что там скорее не ускорение, а 2д замедление.
Да вообще-то гламур нынче довольно резвый и в половине тестов запросто втыкает другим видам ускорения.
> Только 3д без этого замедления работать не будет)
Это не так. Это 2D без этого 3D работать не будет. А не наоборот. Такие вот чудеса истории.
Для это есть страшное для тебя слово - KMS, драйвер modesetting через него работает :) Ему glamor не нужен.
> него работает :) Ему glamor не нужен.Ну так и ускорения 2D не получишь :)
Вообще-то получишь.
> Вообще-то получишь.Что и как будет "ускорено"? Ну, допустим, "буфер кадра" будет не очень тормозливый. Но все что сверх того - вы там как-нибудь сами будете делать. В случае DDX через гламур - помню что дошли до рисования фирменных иксовых трапеций и того что на них основано шейдерами. И одно дело если это GPU на своей стороне посчитает и другое если все это самому обсчитывать.
При том такая фигня с вообще всем рендерингом будет.
> Что и как будет "ускорено"? Ну, допустим, "буфер кадра" будет не очень
> тормозливый. Но все что сверх того - вы там как-нибудь сами
> будете делать. В случае DDX через гламур - помню что дошли
> до рисования фирменных иксовых трапеций и того что на них основано
> шейдерами. И одно дело если это GPU на своей стороне посчитает
> и другое если все это самому обсчитывать.
> При том такая фигня с вообще всем рендерингом будет.ты днище. Читай матчасть.
> Там зависимость была опциональная, ускорение 2D шло не через Mesa.Так у R600 и сейчас EXA осталось. А для RadeonSI всю жизнь только гламур и был. Наверное именно поэтому у бздюков GCN не работают - там для даже 2D ускорения надо чтобы нормально работала вся инфраструктура.
> А сейчас на RadeonSI в xorg-server-1.17 всё (2D и 3D) будет идти через Mesa (OpenGL).
Оно всегда так и было, EXA и прочая для SI никто никогда не кодил. Нельзя оторвать то чего не было, изя :)
Там без гламура 2д как-то работает (в общем-то быстрее чем с гламуром). на radeonsi (>=radeon 77xx)
а на более старых картах llvm не нужен. Гламур впрочем тоже.
Так что не надо врать
> Теперь владельцам AMD Radeon нужно будет устанавливать LLVM для компиляции шейдеровНа третий день Зоркий Глаз заметил что у сарая нет стены.
RadeonSI применительно к иксам ВСЕГДА работал ТОЛЬКО через glamor. А просто потому что других вариантов ускорения никто не кодил.
)))))))))))))
> После шести месяцев разработки анонсирован (http://lists.x.org/archives/xorg-announce/2015-February/0025...) релиз X.Org Server 1.17.Кстати, NVIDIA поддержала X.Org Server 1.17 ABI в новом выпуске nvidia-driver-346.35: http://www.nvidia.ru/download/driverResults.aspx/81343/ru
И на днях драйвер портирован на FreeBSD: http://www.freshports.org/x11/nvidia-driver/
Т.е. вы сначала читаете описание к драйверу и потом устанавливаете, а не устанавливаете а после ошибок начинаете читать описание? Хм ...
Узбагойтесь, нормальных всё же значительно больше.
Под ручку этих грабель на лбу уже вмятинка имеется.
Баян.
http://www.nvidia.com/Download/driverResults.aspx/80134/
http://www.nvidia.com/Download/driverResults.aspx/80647/
>Другое значительное улучшение связано с проведением оптимизации производительности архитектуры 2D-ускорения GLAMOR, в которой для ускорения 2D-операций используется OpenGL и шейдеры. GLAMOR поддерживается в драйверах RadeonSI, Nouveau и Intel, и используется в XWayland, прослойке для выполнения немодифицированых приложений X11 в окружении на базе Wayland.Вот бы оно наконец перестало артефактить на radeon 7750
Хотя производительность это тоже хорошо, т.к. она там сильно низкая
> Вот бы оно наконец перестало артефактить на radeon 7750
> Хотя производительность это тоже хорошо, т.к. она там сильно низкаяКакие артефакты? Где?
> Вот бы оно наконец перестало артефактить на radeon 7750А где у вас артефакты? И какая версия ядра, llvm, mesa, иксов и их ddx-драйвера?
У него NabrOS. Отсюда и все проблемы.
> У него NabrOS. Отсюда и все проблемы.Ах, у него в операционке проблема :)
Что поломали сейчас в угоду поттерингам?
xf86-video-modesetting Вроде поддерживает GPU hot plug. Но раньше при этом он не позволял 3D. Теперь это исправлено?
> Но раньше при этом он не позволял 3D. Теперь это исправлено?А иксы 3D не занимаются, между прочим.
Всё верно, но они инициализируют dri интерфейс. Без этого оно не будет выводить шестерёнки.
> Всё верно, но они инициализируют dri интерфейс. Без этого оно не будет
> выводить шестерёнки.Совершенно не обязательно. См. например какой-нибудь там glmark2-drm - GL есть, а иксов - нет. Ему не требуются иксы для рисования 3D в GL покруче шестеренок.
> xf86-video-modesetting Вроде поддерживает GPU hot plug. Но раньше при этом он не
> позволял 3D. Теперь это исправлено?Сам себе отвечаю - работает!
http://www.gearsongallium.com/?p=1564
>GLAMOR поддерживается в драйверах RadeonSI, Nouveau и Intel
>Intelэто уже не правда, месяц или два назад гламор выбросили из дров интела.
> это уже не правда, месяц или два назад гламор выбросили из дров интела.С дуба рухнул? Ну или как насчет пруфлинков?