> Вайленд тоже жрет больше. Причем больше, чем X-ы. Но это другое!В вот именно вяленде вроде бы нечему много ресурсов жрать. Чему много проца или рамы жрать в интерфейса согласования surfaces, лол. Он услуги навороченого рендера не предоставляет же.
А если какие-то программы удумают ресурсы на свой рендер жрать (их при этом целиком тулкит рендерить должен - в контексте процесса самой программы) - окей, вот к этой программе и вопросы. При чем тут вяленд? Ну и при этом по крайней мере жиртреста сильно виднее в смотрелках процессов.
> Вы путаете возможность работы и размер картинки.
Если на вон том LCD у матрицы 1920x1080 пикселей, для возможности работы с ним в нормальном виде надо никак не менее 6Mb VRAM для 1 буфера. А два... идея, давайте 256 цветов сделаем! А если 16 цветов... вообще FullHD будет :)
А еще - знаете, я готов пожертвовать 6 мегов на процесс чтобы его рендереный буфер - вплоть до всего экрана размером - был. И всегда можно было БЫСТРО на экран выдать ЭТО. Актуально при операциях с окнами и проч. Мксы так устроены что ререндер программы толкают при каком либо перекрытии окна. Это экономит оперативу на буфер, но если программа навороченная, операции с окнами вызывают сотни ререндера, это дико тупит и проц грузит опять же. Когда оперативы было 4 мега на все такое решение имело смысл. Когда даже в одноплатнике менее гига редкость, извините, но это не то место где RAM надо было экономить ценой такого performance hit и факапа UX. Даже андроид этим вроде не страдает.
> Зачем на такой конфигурации FullHD?
Затем что это минимальный типовой монитор десктопа ща? У ноутов бывает и поменьше конечно, но оптимизить логично под типовые кейсы а не экстремумы.
> На 4MB QXL драйвер в QEMU нормально FullHD выдает.
На 4Мб чего?! QXL виртуальный интерфейс же?! ИМХО где-то внутрях драйвера оно аллоцирует себе столько буфера сколько надо было и работает с этим. Оно ж знает что это виртуальная абстракция. А если пытаться честно эмулить хардварную видяху с энным VRAM, по идее на видяхе с 2Mb VRAM разрешение на 24BPP будет ограничено меньшей величиной. Долбилке в провод просто неоткуда данные взять на вон то будет с тем BPP.
> Да. Plasma там тупит, но Mate и LXQt работают.
> Или вы скажите, что меня QEMU жестоко обманывает, когда в конфиге ВМ
> показывает размер VRAM 4194304 байт?
Я честно говоря даже и не знаю что там QXL имеет в виду под "VRAM" в этой ситуации. С него и динамически реаллоцировать станется, имхо. Он же изначально виртуальный интерфейс. Или как вариант BPP ниже: с 16BPP вроде в 4 мега может получиться, впритык. Но я не думаю что QXL честно эмулит именно VRAM и долбилку на экран именно как в видяхе.
> Не знаю. На оффсайте висит предупреждение, что на такой конфигурации вайленд может
> работать только без WM.
Урл? Может это они подстраховались на хранение буферов с видом программы?
> Нагрузка от вайленда еще больше. Возьмем малинку четвертую, Plasma на иксах греет
> камень до 60 градусов без дополнительной нагрузки. Plasma в Waylend до
> 88 градусов. В обоих случаях Цельсия.
Это какие-то очень абстрактные псевдомаркетинговые заявления в стиле "погрузим газету в серную кислоту, а наш журнал в дистиллированую воду". Непроверяемые, потому что не указано вообще ничего. Я предпочитаю более инструментированные и научно обоснованные данные, увы.
> А разве у Мали не свой отдельный чип памяти?
Нет конечно, он как правило только считалка. Добавочный чип это лишние деньги, жаба. Как максимум ему некий резерв памяти откусывают от DRAM, не более того. И у контроллера дисплея (как впрочем и всех интеграшек без VRAM) тоже фреймбуфер из системной оперативки тягается. Так что на хилом одноплатнике с тощей шиной RAM (e.g. 1 16-битный чип на все) даже просто вывод FullHD картинки кушает серьезный процент бандвиза шины RAM и просаживает систему. Потому что так то это поток около 355 мегов в секунду на дисплей в минус от псп памяти. Для более жирных конфигураций меньшая проблема, не такой большой процент псп DRAM.
По этой причине на одноплатниках рекомендуют дизаблить видеовыход если он не используется - дает некий бонус к перфомансу разгрузкой шины от активности "долбилки в провод".
> На 775 сокете много процов и чипсетов под них, которые не могли
> от ОЗУ откусить больше.
Я не знаю что там BIOS делает но драйвер именно GPU в линухе даже с настоящей хардварной VRAM умеет в нечто типа "свопления" в системную, это GTT кажется называется. И если VRAM не хватило на все текстуры, часть в оперативке будет сложена (динамически откушаной из системы). Но разумеется когда их становится надо, передача их в GPU совсем не то что из локальной дискретной VRAM взять, сразу перфоманс обваливается. Но это только DGPU с настоящей VRAM касается. Остальные делили бандвиз и место в системной DRAM на всю толпу что так что сяк. И я не уверен что линуксный драйвер вообще как-то учитывает настройки BIOS. Он с видяхой нативно работает, на BIOS (и VBIOS) ему довольно пофиг по идее при этом.
> Естественно, если графика там встроенная SIS или Mali.
У MALI основной трабл в том что бандвиз DRAM делится на все и вся. Да и старые версии так то достаточно базовы по возможностям, а более новые - лицензировать новый IP блок денег стоит, жаба штука такая.
> Где на таких платах аппаратный декодер? Кодека еще не было, когда платформа
> на указанных процах появилась.
В смысле? В проц встроен. Как отдельный IP-блок VPU. У этих VPU называется Cedar.
Раз! https://linux-sunxi.org/H3 - в описании проца H.265 упомянут.
Два! https://linux-sunxi.org/Sunxi-Cedrus - драйвер этого VPU в майнлайне.
Три! https://linux-sunxi.org/Mainlining_Effort - общий таймлайн кого когда майнлайнили.
И так у почти всех мелких. У rockchip какой-то свой VPU, и так далее. Драйвер в конечном итоге вывешивает типовые апи типа VDPAU и VA-API, софт ничего про детали не знает.
А вон те распасы с V4L2 и mem2mem устройствами на самом деле нужны чтобы поток с камеры загонять в такую железку в режиме кодирования - и получать "хардварно-кодированый" поток с камеры (да, это технически 2 разные железки обеспечивают). А, да, и сплюнуть нежатую копию на surface экрана (видоискатель) так то лочгиный кейс. Ну что, дорогой Xorg, потянешь это? :) А пока майнлайн только стартует это направление ведроиды там видимо юзают какие-то вендорспецифичные костыли. Вероятно перейдут на штатный интерфейс, когда это более-менее взлетит для всех. Вэйланд этим идеям с его структурой не сильно враждебен, ему плюс-минус surface вообще о чем?
> Наверное, Blender через астрал рендерит.
Через 3D акселератор, вероятно. Типа MESA. Эта штука Xorg для основного потока данных не пользуется и у нее там свой собственный интерфейс к DRM/KMS. Совершенно в обход иксов. Да, представляете, bulk данных вулканов и GL через иксы вообще не идут. Потому что те загнулись бы с таких потоков. Так иксы и перестали быть центром вселенной. Очередной клиентик к DRM/KMS, весьма голимый и проблемный. За что его и не лю все причастные к тому гранд-рефактору.
> И при этом еще имеет на Waylend регулярно зависает.
Было б это у меня я бы побеседовал с багом по душам и стало б ЗБС. А так могу посочувствовать, оказать моральную поддержку, или что там. Но это не остановит наступление будушего.
> Ну так дистр-то современный, собственно такой, который вы мне предложили поставить.
Я честно говоря не знаю что там у Патрика сейчас на уме. Сами слакварщики чаще всего компетентные крутые перцы, но это подразумевает и умение решать свои проблемы.
И я не особо понимаю какие решения есть. Да, в вэйланде тоже есть shortcomings дизайна. И баги. Но оно по крайней мере не враждебно на уровне архитектуры _современным_ кейсам, типа, вот, видео "полухардварно" на отдельный surface выдать, может даже как видоискатель камеры, дескать (==тредования к латенси и скорости). Иксы под такие хотелки не делали в принципе. Если что у современных display controller под это бывает отдельный хардварный surface с хардварным микшированием сделан. И самое эффективное что может захотеть плеер - выгружать видео воооон туда если железо так в принципе умеет. А в случае VPU плеер в идеале может стать чуть ли не коммутатором потоков и парсером форматов, когда нежатые данные -> VPU, расжатый результат -> video surface. Так даже дохлое железо сможет расжать - и даже сжать - довольно приоличный кодек в реалтайм. Разумеется битрейт-качество у реалтайм энкодера хуже софтварного, зато в реальное время укладывается и можно, вот, видео камерой снимать. А чего ради это все должно быть в мутной нестандартной вендорской проприетари и самопальных surface flinger'ах всяких? А обычным линуксоидам, типа, это счастье нельзя чтоли? Вот с чего бы?!
