> Есть вещи типа 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, но бажит он знатно и память ест гигабайтами. Надеюсь открытый лучше получится.
