Разработчики OpenWRT объявили (http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel...) о переводе дистрибутива на стандартную Си-библиотеку Musl (https://www.opennet.ru/opennews/art.shtml?num=39365) вместо ранее используемой uclibc. Изменения внесены в trunk-репозиторий и не отразятся на готовящемся релизе OpenWrt 15.05 (https://www.opennet.ru/opennews/art.shtml?num=42290). Musl отличается полноценной поддержкой стандартов и более высокой совместимостью с Glibc, сохраняя такие свойственные uClibc особенности, как небольшой размер, низкое потребление ресурсов и высокая производительность.URL: http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42439
А в чем причина?
Судя по тексту новости, в необходимости поддержки стандартов.
ну не только, судя по регулярно обновляемому сравнению фич здесь: http://www.etalabs.net/compare_libcs.html musl превосходит конкурентов чуть менее чем везде, сохраняя, однако, несовместимости с glibc в сторону POSIX-behaviour.
Новость безусловно позитивная, потому что OpenWRT это не какой-нибудь эзотерический дистр и это должно заставить разработчиков повыковыривать GNU артефакты из своих творений, что приведет к увеличению совместимости, например, с BSD-like libc и вообще.
Эээ, накой разрабам бсд лайк вместо уже готовых пусть и костылей.
> Эээ, накой разрабам бсд лайк вместо уже готовых пусть и костылей.Эппле с Майкрософтом и пр.проприертарщиками Мира во всю пилят замену копилефтному. "Свободные" Анонимы OpenNET-а их в этом полностью поддерживают. OpenWRT-ешники в тренде!
> во всю пилят замену копилефтному.сам-то замену всему испаноязычному на всех форумах пишешь.
> Анонимы OpenNET-а их в этом полностью поддерживают. OpenWRT-ешники в тренде!Ога, микрософт и жоппл прямо в восторге от бизибокса и прочих линукскернелов и подводных лодок, которые под GPL.
> и это должно заставить разработчиков повыковыривать GNU артефакты из своих творений,
> что приведет к увеличению совместимости, например, с BSD-like libc и вообще.Ога, особенно GPLный u-boot и прочие бизибоксы. А уж как некрофильствующие бздюки хотят себе какой-нибудь u-bus! :)
> что приведет к увеличению совместимости, например, с BSD-like libc и вообще.Эпическое ламерство. Для начала - у uclibc с совместимостью намного больше проблем чем у остальных. Потому что совсем мелкий. И если уж кто хотел злостной совместимости с минимальным субсетом фич, uclibc там как раз и был впереди планеты всей: там шаг влево, шаг вправо - и в uclibc не окажется нужной фичи...
>отличается полноценной поддержкой стандартов и более высокой совместимостью с GlibcВидимо столкнулись с тем, что uClibc ведёт себя странно, а разработчики uClibc утверждают, что это фича, а не баг. Так часто бывает когда у чего-то дохренища форков.
> более высокой совместимостью с GlibcА это, кстати, неправда. В общем же, переход на мюсли - это хорошо для эмбеддед-дистра.
>> более высокой совместимостью с Glibc
> А это, кстати, неправда.Ну почему же? В uclibc обрублено все что можно обрубить и поэтому у него с совместимостью очень так себе. Под него патчить приходится достаточно ощутимо.
Брр, лицензия MIT...
а что не так с ней?
Если коротко - то, что она не GPLv3.
> Если коротко - то, что она не GPLv3.Так, но она же совместима с GPL. Продукт отличный, в чем вопрос, форкай, перелицензируй под GPLv3, развивай.
В эмбеде я исключительно пользователь. Разве что с мелкими контроллерами игрался.
> Так, но она же совместима с GPL. Продукт отличный, в чем вопрос, форкай, перелицензируй под GPLv3, развивай.Там все очень плохо! Коварные бэсэдешники уже вознамеревались стырить код у отважных разработчиков линукса и отдать его проприетарщикам! https://docs.freebsd.org/cgi/getmsg.cgi?fetch=2991+0+archive...
Не дадим подлому микросовту возможность паразитировать на сообществе! Нужно перелицензировать musl на GPLv3!!! А еще лучше на GPLv4!!!
> Так, но она же совместима с GPL. Продукт отличный, в чем вопрос,
> форкай, перелицензируй под GPLv3, развивай.Ещё один дурак, не осиливший чтение лицензий. Совместимость с GPL вовсе не означает, что можно взять чужой код, нашлёпнуть сверху GPL и спокойно развивать как ни в чём не бывало.
>> Так, но она же совместима с GPL. Продукт отличный, в чем вопрос,
>> форкай, перелицензируй под GPLv3, развивай.
> Ещё один дурак, не осиливший чтение лицензий. Совместимость с GPL вовсе не
> означает, что можно взять чужой код, нашлёпнуть сверху GPL и спокойно
> развивать как ни в чём не бывало.Расскажите пожалуйста более развернуто об этом моменте - довольно актуально.
В общем случае, если происходило перелицензирование, то разумеется история сохраняется, более того, можно обратно из GPL в MIT наверное.
> Совместимость с GPL вовсе не означает, что можно взять чужой код, нашлёпнуть сверху GPLЕсли лицензия не запрещает изменения - тогда можно. Проприерасы так делают из суперсвободных BSD, MIT и прочих опачей EULA. Но можно и GPL сделать, если хочется.
Берешь и фигаришь свои изменения под GPL. А остальной код может быть и под BSD/MID/Apache, только если кто прихватит это пополам с вашим GPLем, таки требования этого GPL придется уважить. За такие свойства пропирерасы-зажимасы побаиваются GPL, и на это у них есть некоторые причины. Неудобно на GPL паразитировать. И чревато.
> Если коротко - то, что она не GPLv3.так и Линукс тоже
Да. GPLv2 - хуже, чем хотелось бы.
> Брр, лицензия MIT...Ну, знаешь, даже гнутый glibc допускает линковку с проприетарными программами. И этим очень даже пользуются - достаточно на steam какой-нибудь посмотреть. Что особено забавно - проприетарщики как обычно вытерли грязные сапожищи о тех кто перед ними так расстилался. Решив что лицензия либы - не так уж и мешает, коли с ней проприетарь линковать можно.
В декабре делал сборку под проект, решил ради интереса попробовать musl. Патчить софт пришлось не мало, но все гораздо проще в этом плане чем с uclibc.
Можно немного подробнее? Какие были проблемы, что не получилось исправить? Выложите патчи, дабы проще было решится попробовать musl. А то все никак не созрею :)
Да проблем особых не было. Что-то припоминаю в хидерах чего-то не хватало, приходилось макросы делать. Ну пришлось повозиться с llvm, правда нужную мне версию так и не победил, пришлось с более старой выкручиваться. С мелочью как правило все просто. А так необходимое окружение, иксы, простенький вм, софт сетевой под проект(консольная и графическая часть) все в итоге завелось и работало. Особого профита кроме сокращения размера прошивки не было.А по поводу патчей, в качестве тулчейна я брал гентушный stage3 c musl, в портежах на тот момент уже вовсю начинали мелькать патчи. Ну и сейчас уже AlpineLinux должен хорошую базу патчей наработать под musl(посмотри их git), думаю вам этого заглаза будет. И мне не надо ничего вытаскивать, собирать в кучу.
> Да проблем особых не было. Что-то припоминаю в хидерах чего-то не хватало,
> приходилось макросы делать. Ну пришлось повозиться с llvm, правда нужную мне
> версию так и не победил, пришлось с более старой выкручиваться.Дык llvm вообще багодром зверский. Что ни говори а если надо ехать а не шашечки, gcc намного предсказуемее. А зажимать сорец компилера лично мне нафиг не упало и поэтому его GPLность мне не мешает.
Не llvm, а цланг и его libclang++, и не багодром, а соответствует стандартам, которые заявляет, а не слово такое есть в английском cherish(лелеет, опекает) баги, которые они там наделали и везут из релиза в релиз, которые называют GNU фичами, как одна контора из Сиэттла.
И из-за которых в кейсах, где девтим в основном сидит на маках, а на в продакшне линукс выплывают эпичные Shrodinger bugs.
> Не llvm, а цланг и его libclang++,Меня конкретно llvm волнует. И он таки багодром. С libclang++ и шлангом вы там сами сношайтесь.
> и не багодром, а соответствует стандартам, которые заявляет,
К счастью это не мои проблемы. Меня только llvm интересовал и глюков в оном мне хватило выше крыши. Там баг на баге и багом погоняет, куда ни ткни.
> И из-за которых в кейсах, где девтим в основном сидит на маках,
> а на в продакшне линукс выплывают эпичные Shrodinger bugs.Так и надо этим яблочным пи...сам :)
uClibc очень своеобразен, и не все ПО может с ним работать без модификации. Тогда как Musl это в первую очередь поддержка стандарта c99 и в большей степени бинарная совместимость с glibc
а как это отразится на обычном пользователе?
Ну теперь, например, можно будет поставить какой-нибудь postgresql на домашний роутер, потому что musl не кастрирован по фичам как uclibc, который создавался для эмбедовок старой школы, причем работать он будет с минимальным оверхедом.
> Ну теперь, например, можно будет поставить какой-нибудь postgresql на домашний роутер,Не, простым пользователям на роутере не нужен pg. И нужен офис, виртуализация и джавва!
и всё это в докере
Вообще это длинная история, что нужно простому пользователю от эмбедовок. Однажды GNU/Linux уже проиграл войну за десктопы, теперь он проигрывает новую войну эмбедовкам новой школы. Взгляните на некоторые новые анонсы: телеки с ютюбом на Firefox OS, микроволновки с OpenCV на Андройде. Это конечно тоже линукс, но что могут предложить апологеты традиционного GNU/Linux? Иксы, которые устарели лет 20 назад, а их тащут потому что боятся сломать совместимость, а Ульрих тащит свое glibc, который в 10 раз жирнее новенького мусла, и который забагован и не везде совместим, но баги не будут править, чтобы ничего не поломать. И там есть куча еще в активе вещей, от которых бы следовало избавиться уже давно.
Musl тут конечно не панацея, но неплохой такой шаг, чтобы это болото как-то расшевелить.
Я тут на днях как раз разбирался куда уходит память у андроида.Минимальная работоспособная система 130-140MB (из пользовательских приложений только home screen).
GNU/Linux: ядро/драйвера/Xorg/dwn/st/mc/conky - 20MB. И это полноценный десктоп, а не недо ОС на которой нельзя решать серьезные задачи.
Один только Firefox под андроид - минимум 120MB. Думаю с Firefox OS дела обстоят не лучше.
Минимальный hello world под андроид - 5MB. Реальное простое приложение (типа калькулятор) - 10-15MB.
GNU/Linux проигрывает не по потреблению ресурсов, а по простоте клепания сторонних приложений. Да и это не такая уж большая проблема. Все остальное - маркетинг.
Но если поднять на GNU/Linux иксы с тачем и всеми делами + запилить что-нибудь на Qt в качестве UI, то там получатся ровно те же 150MB RSS. Но есть нюансы. Чтобы накидать что-то подобное для Android нужно потратить пару вечеров, а для того чтобы наворотить это на GNU/Linux на базе какого-нибудь SoC нужно будет потратить неделю только для того, чтобы завести GPU. Тут же все за свободное ПО, против БЛОБов.
> Но если поднять на GNU/Linux иксы с тачем и всеми делами +
> запилить что-нибудь на Qt в качестве UI, то там получатся ровно
> те же 150MB RSS.Давайте уж на яве, чего уж там мелочится :)
Речь о том что под андроид просто меньше не получается. И я не думаю что драйвер тача и тачпада сильно разлетаются в аппетитах. Запустил сейчас blender - +69MB RSS. И это при том что под андроид и другие недо ОС просто нет приложений подобного уровня.
> а интересы сообщества его не интересуют.Ну всё правильно. Но потом и получается, что память оптимизировать его тоже не интересует - как же потом продавать новые смартфоны с 3 гб :-)
> И это при том что
> под андроид и другие недо ОС просто нет приложений подобного уровня.Может, хватит уже расписываться в собственной некомпетентности, а?
Слово demo и дата 19-08-2012 не о чем не говорит?
Нет. Это приложение, и оно есть под андроид, а ты сболтнул чушь.
Ну да. А еще у меня где-то валялся нативный CorelDraw 3 (1991г) для unix. Под линуксом тоже работал. Так что можете смело говорить всем вендузятникам, что под линуксом тоже есть нативный корел.
При том мне кажется что ты в кореле 1991 года наработаешь больше, чем этот чудак на мусорном ведре с демо-версией блендера.Девайсы на андроиде заточены на потреб-дство. Там нормальных средств ввода по дефолту нет, и система оптимизирована на удобное хавание хомяками контента и сервисов, с сливом данных партнерам и вообще.
Поработать в ведроиде? Cool story. А кто и что в ведроиде так уж прямо наработал? Там делают анимации? Круто рисуют? Сочинают музыку? Пишут код? Проектируют сооружения и устройства? Нет? Ну надо же. А вроде и у адобы что-то есть. И у автодеска. Только вот проще влезть на намыленный фонарный столб в противогазе и ластах чем на ведроидном девайсе в CAD что-то делать. Средства ввода больно уж дубовые.
> на GNU/Linux на базе какого-нибудь SoC нужно будет потратить неделю
> только для того, чтобы завести GPU. Тут же все за свободное ПО, против БЛОБов.Ну и как BLOB-ы тебе ускорят формошлёпство? Езжай уже к бабушке ... :)
На что, на что - на зиготу ))))) они же там аналог разделяемых библиотек не осилили сделать в своей яве/дальвике (понятно, что это нетривиально, язык же управляемый) и поэтому для экономии памяти сначала создаётся процесс zygote, подгружает все библиотеки и фреймворки, и в дальнейшем процессы форкаются от него - типа, чтобы память через copy-on-write шарилась.И есть у меня подозрение, что это в итоге всё равно приводит к накладным расходам...
Правда, с другой стороны, много расходуется под всякие графические буферы и подобное, на этом уже не так просто сэкономить.
Ну и Firefox - он и на десктопе, знаете ли, не 20 кб потребляет :-)
> Ну и Firefox - он и на десктопе, знаете ли, не 20
> кб потребляет :-)Когда программа, предназначена для просмотра гипертекста, потребляет больше чем программа 3d моделирования (содержащая в себе помимо прочего нелинейный видеоредактор и собственный gui), то наверное что-то с первой программой не так ...
HTML (нескольких версий, пара сотен поддерживаемых тэгов и пара тысяч параметров к ним)XML (нескольких версий)
встроенный проигрыватель аудио
встроенный проигрыватель видео
встроенный модуль векторной графики
встроенный ЯП (java script)
Я что-то забыл?
> HTML (нескольких версий, пара сотен поддерживаемых тэгов и пара тысяч параметров к
> ним)
> XML (нескольких версий)несколько десятков 3d форматов
> встроенный проигрыватель аудио
> встроенный проигрыватель видеоесть и то и другое во всех форматах (ffmpeg) как на вход так и на выход (там ведь редактор, а это на порядок сложнее)
> встроенный модуль векторной графики
2d форматы + 2d редактирование
> встроенный ЯП (java script)
python
> Я что-то забыл?
social api и прочий крап :)
Вы говорите, как я понимаю, о какой-то конкретной программе трёхмерного моделирования. О какой?3D max потребляет больше, чем IE ("лучшим достаточно лучшего"). T-flex и Компас (для параметрического моделирования) тоже.
blender
>> встроенный ЯП (java script)
> pythonА что - питон? Он тормознее JS в разы (а то что есть speed to memory tradeoff мы не забыли?). А дряни на бидоне нынче какая-нибудь убунта норовит приволочь более чем достаточно. Вон например значок принтера. Тривиальная программа с 3 кнопочками - показывает аж список жобов cups-а и полторы меню. А 30M RSS - как с куста. При том что 99.9(9)% времени эта хня ничего не делает а у половины юзерей так и принтера то даже нету. Но 30 метров оперативы эта буита на бидоне откушает, для профилактики. Такая же хня с аплетом для блупупа. Вот так ножницами поработаешь, вышибив подобный крап - пару сотен мегов памяти можно отвоевать, ничего особо не потеряв :).
>>> встроенный ЯП (java script)
>> python
> А что - питон?Там он идет как скриптовый язык для быстрой автоматизации рутины. Сам blender - c/c++. 3dsmax кстати тоже python для скриптов начал использовать, не смотря на то, что у них уже был свой maxscript.
> Там он идет как скриптовый язык для быстрой автоматизации рутины.Как язык автоматизации бидон полный трэш, потому что постоянно ломают совместимость. Доходит до того что какой-нибудь апдейтер убунты феерично валится при попытке апдейта с длинным стэктрейсом. По которому прошаренный питонист догадается что это означало на самом деле "версия питона не та". Остальные же видят только три страницы питоногалиматьи.
Вот лично мне такая автоматизация не требуется. Мне в результате оказывается проще самому пойти и прописать новые репы в sources.lst - это проще, быстрее и безглючнее чем пытаться переубедить эту вашу бидоноавтоматизацию, быстро автоматизированной в стиле тыр-пыр-восемь-дыр.
> Сам blender - c/c++.
Только зачем-то кучу бидоноблевотины тянет. При том бидон не имеет ничего общего с синтаксисом си и си++, по поводу чего для меня он - просто совершено левый пришлепок который вообще никуда не упал.
> 3dsmax кстати тоже python для скриптов начал использовать, не
> смотря на то, что у них уже был свой maxscript.Это все круто, но я о питоне знаю только то что он существует. И создает своим существованием кучу неудобств из-за несовместимости версий. А его бэйсикообразный синтаксис нацеленный на построение идиoтов, пускающих пузыри в стойло меня не улыбает. И вообще, давно известно - "создайте систему которой может пользоваться даже дypaк..." - и на примере питона это отлично видно. Если программа постоянно тормозит, глюкает, плевать хотела на ошибки и прочее - да, это может быть быстро накиданный макет на питончике. Правда когда он отвалится - сломаешь весь мозг, а то и вовсе придется переписывать половину, потому что авторы языка решили что так было не круто и не моложежно, правильно дескать вот так. А вы тут переписывайте давайте вашу системную автоматизацию.
> Я что-то забыл?Офигенную кучу исторических костылей и подпорок с оптимизацией поддержки "тяжелых" сайтов, заумного кэша и других прелестей - типа полноценных ДОМ-бревен.
Особенно "классно", когда огнелисы да вебкито-подобные кушают свои сотни Мб при просмотре нормпльных доков (без свистелок) в формате хтмл.
> Я что-то забыл?Perl HTML - динозавр ,но по стандарту еще потдерживается .(Не интрепретатор на стороне сервера ,а совсем куций огрызок для браузеров )
А можно детальнее? Что-то не сумел я выгуглить это чудо,а интересно...
Описание было в книг
учебнику про перл .Нечего интересного
всего 12 операторов .В основном условное форматирования текста и показ вскрытие текста .
Ага, гипер текста, который на 3/4 js, причем кроссплатформенный под всяких динозавров типа ie6, который переделывает гипертекст всякими бустами до няшного вида, - как ни крути это вэб-программирование мало того что на удаленном клиенте исполняется, так еще и кучу мусора подтягивает по запросу.
Только памяти ff ест в два раза больше blender, даже если он полностью пустой и без плагинов.
А Blender, если ему подсунуть заведомо невалидный файл, точно не упадёт? И инжект произвольного кода в кучу не пропустит? А окна у него в изолированных песочницах? И, разумеется, с разными контекстами безопасности? В браузер потому и пытаются всё засунуть, что он хуже Емакса - полностью сформировавшаяся ОС (и одна из самых юзабельных притом). И просмотрщик веб-страниц, что любопытно, тоже имеется.
А ff умеет физически корректно световой поток фотонов считать? Работать с битностью 16/32 бита на канал? Проводить физическую симуляцию?Понятно что все это сравнения теплого с мягким, но программа позволяющая создавать графику голивудского уровня по определению на порядок (если не на два) сложнее, чем любая программа просмотра.
А у блендера есть 3 аналога с которыми он жестко конкурирует за скорость рендеренга недогруженных файлов?браузер создает множество ненужных объектов которые может понадобятся, а может нет, но в "целом" с ними он работает быстрее, памяти юзает ровно столько сколько есть на "среднем" компе. Если поковырятся в исходниках наверняка можно найти кучу ненужностей, которые при отключении экономят 1-2 % памяти, но столькоже добавляют ко времени обработки, и в зависимости от тестов и жалоб этими фичами балансят памят/производительность.
Короче говоря сложность браузера не ниже, а если вспомнить гиков, которые на js пишут виртуалки и кваки портирую, то получается браузер может тоже, что любой 3д редактор, просто нужна правильная js'ка, но не любой 3д редактор может тоже, что и браузер.
> А у блендера есть 3 аналога с которыми он жестко конкурирует за скорость рендеренга недогруженных файлов?3D рендерингов десятки (как открытых так и закрытых) - конкуренция очень жесткая. Есть как бескомпромиссные - оперирующие не просто rgb, а длинной световой волны. Есть и наоборот ориентированные на скорость.
При моделировании используются миллионы полигонов. Поэтому к оптимизации памяти относятся серьезно. Но и показывать их на экране нужно в реальном времени.
> браузер создает множество ненужных объектов которые может понадобятся, а может нет, но в "целом" с ними он работает быстрее, памяти юзает ровно столько сколько есть на "среднем" компе.
В этом и проблема, что браузер разбухает как на дрожжах без видимых причин - потому что +/-100MB крутых манагеров из мозила ко не волнуют.
> Если поковырятся в исходниках наверняка можно найти кучу ненужностей, которые при отключении экономят 1-2 % памяти, но столькоже добавляют ко времени обработки, и в зависимости от тестов и жалоб этими фичами балансят памят/производительность.
Насколько помню palemoon есть при старте 80-90MB, FF - 120-140. Не сказал бы что palemoon медленнее, скорее наоборот. Opera (на presto) ела еще меньше и работала быстрее.
> Короче говоря сложность браузера не ниже, а если вспомнить гиков, которые на js пишут виртуалки и кваки портирую, то получается браузер может тоже, что любой 3д редактор, просто нужна правильная js'ка, но не любой 3д редактор может тоже, что и браузер.
Тогда gcc круче всех :)
И да у blender'а есть еще и собственный игровой движок.
> 3D рендерингов десятки (как открытых так и закрытых) - конкуренция очень жесткая.Не уверен, аудитория куда меньше.
> браузер разбухае
Все разбухает, чем браузер хуже, такова тендеция, что тупо оборачивают старый функционал в новые обертки.
> Opera (на presto)
до сих пор стоит кое где.
> Не уверен, аудитория куда меньше.Зато грамотная. У каждого рендера есть десяток (а то сотня) параметров которые можно подкрутить и пожертвовать в определенных местах качеством (например больше шума в отражениях, хуже проработка теней в углах) и несколько алгоритмов выбираемых в зависимости от типа сцены (открытое пространство или закрытой объем). Обычно можно подождать 8-24 часа для получения одной качественной картинки, но если речь идет об анимации, то даже 60 секунд - это 1500 кадров - 1.5-4 года! Тут уже начинается поиск рендера который кадр отрендерит за 1-2 минуты с приемлемым качеством.
Любой нормальный 3d'шник знает как настраивать хотя бы пару рендерингов. Да и на сайтах/форумах постоянно проводят сравнения скорость/качество на однаковых сценах.
Лидер для закрытых объемов (интерьеры) среди нечестных - v-ray. Лидер среди честных (физическикорректных) - открытый проект luxrender. Но и у других есть свои плюсы в определенных ситуациях.
> речь идет об анимации, то даже 60 секунд - это 1500 кадров - 1.5-4 года!
> Тут уже начинается поиск рендера который кадр отрендерит за 1-2 минуты с приемлемым качеством.Или поиск фермы для рендеринга. Или портирование на, допустим, opencl (что займет явно менее 4 лет). Ну вон тот GPU из верхушки mid-range - в массово параллелящихся задачах обставляет мой 8-ядерник примерно в 40-50 раз. Если поделить ваше время на 50 - уже становится не так уж плохо. И накрайняк катит даже на единичном компьютере. Ну попыхтит видяхой недельку. А даже мелкая рендерферма с десятком таких компов с нормальными видяхами - справится вообще за полдня. Так что кому надо было именно качество - в общем то все это уже могут. Под майнинг биткоинов целые склады собирали, забитые GPU до отказа. Типичный склад используемый майнерами под ДЦ вообще вам вашу сцену в реалтайме пожалуй посчитает. Если, конечно, вы ее столь массово-параллельно распилить сможете.
> (физическикорректных) - открытый проект luxrender.
ЧСХ, половина смысла в оном - работа с opencl. Считать графику на CPU вместо GPU - совершенно тухлая затея. GPU оптимизирован на массово параллельные операции (там "over 9000" ALU) и память такая же (GDDR5 и т.п. - оптимизированы на скорость в паттернах доступа характерных для графических операций)
>> речь идет об анимации, то даже 60 секунд - это 1500 кадров - 1.5-4 года!
>> Тут уже начинается поиск рендера который кадр отрендерит за 1-2 минуты с приемлемым качеством.
> Или поиск фермы для рендеринга.Цена все равно будет нереальной.
> Или портирование на, допустим, opencl (что займет
> явно менее 4 лет).Не все так просто. Для opencl подходят только простые задачи которые можно исполнять параллельно. Единственное применение честные рендеринги (luxrender).
Но нечестный v-ray на среднем процессоре в 10-100 раз быстрее произведет расчет, чем luxrender на среднем gpu. Качество для обывателя при этом будет почти не различимо.
>> Или поиск фермы для рендеринга.
> Цена все равно будет нереальной.Краудфандинг легко делает "нереальное" простым и доступным. Вопрос в общем то в том насколько всем остальным это надо.
> Не все так просто. Для opencl подходят только простые задачи которые можно
> исполнять параллельно. Единственное применение честные рендеринги (luxrender).Насколько я понимаю, почти все что связано с графикой - параллелится очень хорошо. Поэтому GPU такими и делают.
> почти не различимо.
Однако ж сравнивать разные алгоритмы с разным результатом - не комильфо. А так - честный рэйтрэйсинг в играх например никто не делает. Там тоже приходится "почти не различимо" упрощать. Только т.к. реалтайм жмет - им даже GPU оказывается мало, так что "почти" получается ... ну в общем, "LZ4 жмет почти как LZMA, но в 100 раз быстрее". Правда, "почти" иногда отличается раза в три. Ну а реалистичность картинок зарендереных в реалтайме - понятно какая. Почти настоящая, но с настоящей картинкой никто не перепутает.
> Насколько я понимаю, почти все что связано с графикой - параллелится очень
> хорошо. Поэтому GPU такими и делают.Нет, только простые алгоритмы.
Например реализовать bidirectional surface integrator (http://www.luxrender.net/wiki/LuxRender_Render_settings) уже проблемно. Нормально работает только обычный path tracing.Есть у них реализация сложных алгоритмов на CPU + tracing на gpu - гибридный режим (http://www.luxrender.net/wiki/GPU). На реальных сценах ускорение в 1.5 раза (они говорят что может быть до трех раз, но может быть и медленнее чем без gpu вообще).
Я периодически ковыряюсь с SmallLuxGpu - отдельный проект luxrender'а полностью на opencl. Там хоть немного что-то усложнишь - и приплыли - скорость падает 2-10раз, а может и вообще тупо всю память съесть при компиляции и упасть. Приходится шаманить с кодом и подбирать версии драйверов.
>> почти не различимо.
> Однако ж сравнивать разные алгоритмы с разным результатом - не комильфо.Вот пример: http://www.archi3t.it/public/confronti/prove-flash.jpg
На шум не смотрите - для физически корректных нужно очень много времени для полного устранения шума. Материалы тоже могут немного отличаться - у всех рендерингов они разные и не так просто их подогнать 1-в-1.
> Нет, только простые алгоритмы.Игроделам поневоле приходится делать алгоритмы упрощенными, быстрыми и массово параллелизуемыми. Игроки не рендерферма, ждать не будут.
> уже проблемно. Нормально работает только обычный path tracing.
Да я не сомневаюсь что не любой алгоритм хорошо параллелится. Но GPU делали в основном под игроделов. С их подходами и алгоритмами. Ну и пришли в результате к массивам массово параллельных числодробилок. Если алгоритм хорошо параллелится - он на GPU словит EPIC WIN относительно CPU. А если нет - тогда никакого EPIC WIN не произойдет. У GPU частота невысокая, execution flow control неповоротливый. Если алгоритм плохо параллелится, CPU может взять крутизной отдельно взятого ядра, несмотря на их скромное количество.
> но может быть и медленнее чем без gpu вообще).
Значит такой алгоритм. GPU хорошо работают на алгоритмах которые можно раскидать в максимально параллельном виде. Нечто типа очень массового SIMD.
> 2-10раз, а может и вообще тупо всю память съесть при компиляции и упасть.
А вы это на открытом драйвере? На проприетарном?
> Приходится шаманить с кодом и подбирать версии драйверов.
В открытом драйвере всякий разный грабледром например не сильно редкое явление.
> Вот пример: http://www.archi3t.it/public/confronti/prove-flash.jpg
Ну и? У разных алгоритмов довольно разный результат.
> всех рендерингов они разные и не так просто их подогнать 1-в-1.
Там разное по-моему вообще все что может быть разным. Отражения посчитаны по разному. Где-то выключатель на стене почти не видно, а где-то он виден отлично. Я бы не стал утверждать что это такой уж одинаковый рендеринг.
>>> Или поиск фермы для рендеринга.
>> Цена все равно будет нереальной.
> Краудфандинг легко делает "нереальное" простым и доступным. Вопрос в общем то в
> том насколько всем остальным это надо.Не очень себе это представляю. Допустим скинутся 1500 человек, каждый на нормальный ящик. Соберут ферму. Один человек будет рендерить свой ролик на ней 1 день. Но чтобы отрендерить каждому понадобится 1500 дней. Вряд-ли кто-то захочет ждать четыре года. Да даже пол года - слишком долго.
Дипломники тут узнавали во сколько им обойдется анимация на чужой ферме. Если интересно могу точно узнать, но было дорого.
> 1 день. Но чтобы отрендерить каждому понадобится 1500 дней.Не каждый первый человек умеет делать мувики которые достойны того чтобы их так рендерить. Многие люди могли бы не против посмотреть результирующий мувик. И принести за это немного денег. А найти 1500 людей которые будут часто делать мувики... хм, если у вас получилось, вы счастливый человек :)
> Зато грамотная)) да, но задача общего назначения с кучей костылей во имя совместимости и узкоспециализированная со специалистами которые деньги получают и заинтересованы в результате.
Я писал генератор конфига для железяки и по результату куча мутного кода который анализируе конфик медленне, чем те же параметры по snmp забрать зато генерит конфик идентичный тому, что на железке валяется, а когда вышла новая прошивка и я подправил генерилку под нее, это увеличило время раза в три, понятно что речь о секундах, но сколько режимов разбора у браузера знаете?
А деньги за дыры платить уверенность нужна, что там все достойно, а уверенность появляется когда весь код четко структурирован и сгруппирован, в общем нормально все. Будет новый стандарт html новый js может и не потребуется столько памяти, а пока нет даже понимая как это должно выглядеть.
> уверенность появляется когда весь код четко структурирован и сгруппирован, в общем
> нормально все.Сразу видно что в сырцы FF вы не заглядывали ;) Как вы думаете, сколько нужно времени чтобы сделать патч, чтобы в заголовке окна отображалось только название сайта без имени браузера?
> Будет новый стандарт html новый js может и не
> потребуется столько памяти, а пока нет даже понимая как это должно
> выглядеть.Будет поддержка старого + нового - меньше точно не станет.
> Сразу видно что в сырцы FF вы не заглядывалиНу вот не факт, хотя на мозилу я давно положил не нравится мне их системы сборки с кучей их библиотек и всяким левым скрапом.
> Будет поддержка старого + нового - меньше точно не станет.
пока интернет не перепишется - да, а потом выбросят, хотя не факт, что новое костылями не обростет. Какбы в том и суть, что конкретики нет, надо чтобы было хорошо, а как именно хз, вот и рождаются всякие флеши, жквети и дарты, и хрен пойми что.
Хотя вот щас подумалось о виртуальной машине, которая будет прям исполняемый код с сайта грузить, а там хоть образ оси, хоть кино, хоть вордовский файл, ну и настройки на уровне виртуалбокса)))
> Хотя вот щас подумалось о виртуальной машине, которая будет прям исполняемый код
> с сайта грузить, а там хоть образ оси, хоть кино, хоть
> вордовский файл, ну и настройки на уровне виртуалбокса)))Проще наоборот - вместо сайтов грузить видео с переменным фрейм рэйтом и отсылать события от мыши и клавиатуры - ИМХО может даже быстрее будет, чем сейчас :) А вместо браузера чуть доработанный видеоплеер.
> Проще наоборот - вместо сайтов грузить видео с переменным фрейм рэйтом и
> отсылать события от мыши и клавиатуры - ИМХО может даже быстрее
> будет, чем сейчас :) А вместо браузера чуть доработанный видеоплеер.А оффлайн? да и проблем с кодеками и нормальным масштабированием, что у видео, что у картинок много, сколько лет уже родить не могут стандарт, пнг хорошо, но джпег все не дохнет))
>> Проще наоборот - вместо сайтов грузить видео с переменным фрейм рэйтом и
>> отсылать события от мыши и клавиатуры - ИМХО может даже быстрее
>> будет, чем сейчас :) А вместо браузера чуть доработанный видеоплеер.
> А оффлайн?Save as bitmap/pdf.
> да и проблем с кодеками и нормальным масштабированием
Сервер должен сам генерировать видео с запрошенным разрешением и менять его при смене размера окна.
Прикольная history получится - перемотка видео файла :)
> Проще наоборот - вместо сайтов грузить видео с переменным фрейм рэйтом и
> отсылать события от мыши и клавиатурыВот только сервера для этого потребуются адские. Одно дело просто сделать чуть ли не sendfile() и совсем другое - дергаться на каждый пшик юзеря. Ну то-есть dash на самом деле что-то такое немножко в ту сторону. Но - немножко. И как я понял, у того же гугля - таки сегменты видео это все-таки просто файлы, отгружаемые с сервака. Только "кусочками". И если при переходе к очередному кусочку понятно что бандвиза напирмер не хватает - можно брать кусочек с разрешением пониже. Его и декодить попроще и бандвиза меньше.
> А вместо браузера чуть доработанный видеоплеер.
И кому это будет такое надо? Веб является инкарнацией мультимедия в самом прямом смысле этого слова: он объединяет разнотипный контент в одно представление. А этот ваш чуть доработанный видеоплеер что может? Как максимум, субтитры показать в лучшем случае?
> Только памяти ff ест в два раза больше blender, даже если он
> полностью пустой и без плагинов.К сожелению движок Webkit прекратили потдерживать :-( А так если нужен очень компакный браузер смотри QtWeb -13 мб на диске правда 4 года уже не обновляется ,есть версии под другие опереционки .
У браузеров на webkit (qupzilla, midori) примерно такое потребление памяти как и у ff. Нужен новый движок, который будут развивать не компании и маркетологи, а сообщество. Тогда возможно будет шанс увидеть что действительно достойное. Жаль, что opera так и не открыла исходники, а просто похоронила проект. Остается netsurf, но пока к нему не прикрутят js, он не особо интересен.
> который будут развивать не компании и маркетологи, а сообщество.Когда-то таким была мозилла. А потом туда пришли маркетологи и все изгадили, т.к. на их зарплаты стало требоваться в разы больше денег и мозилле пришлось заняться веб-вымогательством и раборго^W продажей userbase по сходной цене.
> К сожелению движок Webkit прекратили потдерживать :-(Классический "Эппловский" Webkit не прекратили поддерживать, просто порт под Qt забросили, и зачем-то сделали порт Гугловской версии, которая пожирает память гигабайтами, порт же gtk-webkit собирается в том числе из транка. Из браузеров на нем есть Midori(но они пока не поддерживают Webkit2 т.е. там версия старовата пока) и есть Ephiphany с убогим UI, но возможностью использовать Webkit из транка.
Памяти, к слову, новые неправославные эппловские вебкиты с новым js на llvm жрут меньше не только поделий на гугловском движке, но и меньше фокса.
> GNU/Linux: ядро/драйвера/Xorg/dwn/st/mc/conky - 20MB. И это полноценный десктопСпасибо, поржал.
> GNU/Linux: ядро/драйвера/Xorg/dwn/st/mc/conky - 20MB. И это полноценный десктоп, а не
> недо ОС на которой нельзя решать серьезные задачи.И какие задачи вот конкретно эта связка решает? Показ внутренних параметров системы на десктоп? Пи..ц какая полезная задача. Знаете, в этом плане самый тривиальный термометр за окном - и то полезнее.
>> GNU/Linux: ядро/драйвера/Xorg/dwn/st/mc/conky - 20MB. И это полноценный десктоп, а не
>> недо ОС на которой нельзя решать серьезные задачи.
> И какие задачи вот конкретно эта связка решает? Показ внутренних параметров системы
> на десктоп? Пи..ц какая полезная задача. Знаете, в этом плане самый
> тривиальный термометр за окном - и то полезнее.Еще раз: минимальный андроид ест 130MB RAM (ни одной полезной задачи, только система). Относительно минимальный GNU/Linux - 20MB. При этом дальше на этой машине можно работать с 2D/3D графикой, аудио, программирование. То есть реально запускать любые десктоп задачи, в отличии от андроида. Если выкинуть st/mc/conky то вообще будут что-то около 10MB ram.
> Еще раз: минимальный андроид ест 130MB RAM (ни одной полезной задачи, только система).Ну так давно замечено что ЯваНеТормозит!!!111 Поэтому хипстеры из гугля сделали минимально легкую систему, с обкоцаным либцэ, surface flinger'ом и чем там еще, чтобы ... обрадовавшись тому как все крЮто и быстро - шустренько прое... преимущества путем использования явы. Сразу стало о-го-го, понадобились 8-ядерники и 64-бита чтобы сотни памяти адресовать. Иначе когда юзерь открывает чатик одновременно с браузером и адресной книгой - систему начинает клинить. Ведь ява не тормозит!!!111
Зато благодаря хипстерам и их рыбам и чятикам - теперь чуть ли не 8-ядерники в размерах чуть ли не спичечного коробка - по цене чуть ли не песка под ногами. Спасибо потреб-душкам за оплату прогресса, чтоли.
> Относительно минимальный GNU/Linux - 20MB.
Однако если попробовать на этих ваших иксах сделать хотя-бы просто анимацию гуя и вообще, чтобы все это не выглядело как винда 3.11 - иксовый процесс мигом начинает трескать ресурсы как свинья помои, становясь первым в топе по нагрузке на проц. А если проца не хватило - в иксы могут упереться ВСЕ и гуй начинает судорожно дергаться вообще общесистемно. Ведру конечно тоже есть куда расти, но там чаще всего по крайней мере можно более-менее убить проблемную задачу. А если кто крепко пригрузил иксы - из графического окружения его вообще хрен прибьешь уже - ведь все стоит колом.
А сколько уязвимостей в иксах нашли за последние пару лет - вообще без комментариев. А много вы дыр в графике ведроида помните? А ведь им пользуются намного больше народа и дыры там ценятся куда выше - из-за возможности долбануть обшинрую аудиторию...
> машине можно работать с 2D/3D графикой, аудио, программирование.
Я что-то не вижу в вашем списке ни компилятора, ни библиотек, ни аудиоредактора, ни тем более чего либо для работы с 2D или 3D графикой. А если все это поставить - там уже будет все-таки не 20 мегабайтов. А ведроид что, он изначально потреб-цкая система. Он не для тех кто созидает. Он для тех кто потреб-дствует. Ну вот и приоритеты там под стать. Хотя кое чему можно поучиться даже у них. Все-таки видео там играется получше. Без дикой нагрузки на проц от паразитного процесса обслуживания графики и без адского тиринга, с которым на моей памяти борятся уже лет наверное пять. С достаточно переменным успехом.
Кто не верит, хотите эксперимент? https://www.youtube.com/watch?v=Czy0pXRRZcs - можете укачать и посмотреть любым плеером какой вам там удобен, как вам там удобно.
Внимание на 15-34 секунды, там где парень с самолетиком. Зарекомендовало себя очень интересным тестом состояния графической подсистемы в плане тиринга - если тиринг есть хоть самую капельку, на этой сцене он очень сильно бросается в глаза.
А что, скажете честно - как у вас это выглядело на этой сцене? Было ли все идеально, без малейших намеков на тиринг? И в каких плеерах/конфигурациях?
> то вообще будут что-то около 10MB ram.
Ну да. У меня какой-то архаичный роутер с максимально обкоцаным ядром 2.4 - умеет грузиться с 2 мегов флеша и 8 мегов оперативы. На всем этом крутится роутер и точка доступа. И даже вебморда какая-то. Но обкоцано по максимуму, нет ни бита, conntrack table мелкий. В общем, "фу таким быть" - умрет на трех юзерях по размеру conntrack-а. А вон тот banana router с его A20 и гигом оперативы за полтинник УЕ - conntrack целого приличного офиса выдержит, пожалуй.
>> Относительно минимальный GNU/Linux - 20MB.
> Однако если попробовать на этих ваших иксах сделать хотя-бы просто анимацию гуя
> и вообще, чтобы все это не выглядело как винда 3.11 -
> иксовый процесс мигом начинает трескать ресурсы как свинья помои, становясь первым
> в топе по нагрузке на проц.Так у андроида не лучше - запустите самый примитивный секундомер и посмотрите top.
> А если проца не хватило
> - в иксы могут упереться ВСЕ и гуй начинает судорожно дергаться
> вообще общесистемно. Ведру конечно тоже есть куда расти, но там чаще
> всего по крайней мере можно более-менее убить проблемную задачу.Хм, запускаю рендеринг или make -j5 (4 ядра) - ничего не тормозит.
> А если
> кто крепко пригрузил иксы - из графического окружения его вообще хрен
> прибьешь уже - ведь все стоит колом.Видел подобное только когда рендеринг (на opencl) жестоко перегружал gpu.
>> машине можно работать с 2D/3D графикой, аудио, программирование.
> Я что-то не вижу в вашем списке ни компилятора, ни библиотек, ни
> аудиоредактора, ни тем более чего либо для работы с 2D или
> 3D графикой. А если все это поставить - там уже будет
> все-таки не 20 мегабайтов.Так 20MB RAM! (vs 130MB RAM у андроида) - я о том о чем и вы вначале: linux с нормальным glibc и остальными библиотеками ест меньше, чем покоцаный android. Применив яву, они просто перечеркнули весь проделанный труд по оптимизации потребления памяти системой.
Сколько занимает минимальная система на диске - не замерял не для linux не для android - не было необходимости.
> Все-таки видео там играется получше. Без дикой
> нагрузки на проц от паразитного процесса обслуживания графикиmpv hd h264 - 10-12% cpu (программно декодирование) + 1% Xorg
> и без адского
> тиринга, с которым на моей памяти борятся уже лет наверное пять.
> С достаточно переменным успехом.
> Кто не верит, хотите эксперимент? https://www.youtube.com/watch?v=Czy0pXRRZcs - можете
> укачать и посмотреть любым плеером какой вам там удобен, как вам
> там удобно.mpv -vo opengl
hd6770 открытый драйвер (glamor) - есть тиринг в оконном режиме (окно растянуто почти на весь экран), в полноэкранном режиме нет тиринга.intel sna - тиринга как такового нет, но на специальном тесте (постоянно движущийся вертикальная белая полоса) есть ели заметные искажения в самом верху, возникающие на одном кадре раз в несколько (3-5) секунд.
> Так у андроида не лучше - запустите самый примитивный секундомер и посмотрите top.Не знаю как там с секундомером, но графику у него при проигрывании видео таки не клинит, с тирингом как-то получше и батарейку паразитный процесс обслуги графики не жpeт. И игры с динамичной графикой отображаются прилично. Хотя ессно те у которых качество графики нормальное - писаны таки на сях++ под libsdl какой-нить, т.к. все мы знаем что "ява не тормозит". Игроделы тоже в курсе :)
>> всего по крайней мере можно более-менее убить проблемную задачу.
> Хм, запускаю рендеринг или make -j5 (4 ядра) - ничего не тормозит.Так они ничего с иксами и не делают - чего б им?! Однако, с иксами вполне реально нарваться на тот факт что при большом потоке запросов от какой-то программы сами иксы упрутся в полку по CPU, обрабатывая запросы от программы. При этом колом в системе встанет вообще вся графика. Потому что тормозит сам дисплейный сервер, упершийся своими меганаворотами в проц. Ну и все программы, соответственно, отрисовываются раз в полчаса, убить программу из гуйного окружения становится ну не то что невозможно, просто это потребует два часа пошаговых стратегий. Иксы - это такой кусок крапа, который достаточно немного пошевелить палочкой чтобы все развалилось КЕМ. Все причастные про это вроде давно в курсе. Что там плохо и с производительностью, и с секурити и много с чем еще. И архитектуре современных GPU оно не соответствует чуть менее чем совсем.
Все пришло к довольно дурному формату: программы все рендерят сами на своей стороне силами тулкитов. А иксам по сути отдают в основном готовые битмапы. А вот с рендерингом битмапов у иксов в плане скорости всегда было "не очень". Это конечно обвешивают костылями, но даже Кейт Пакард таки задолбался (кто там его ругал - можете радоваться, он ушел). В целом работа графики в линухе получается очень так себе. Гордиться таким устройством и свойствами графической системы я бы не стал. В иксы никто не хочет соваться лишний раз, как в помойную яму. И многие спят и видят чтобы избавиться от них и перейти на что-то менее проблемное, типа вяленда какого. Это, заметим, сами разработчики так к иксам относятся.
> Видел подобное только когда рендеринг (на opencl) жестоко перегружал gpu.
На самом деле достаточно 1 неудачно написанной программы - и оно так станет без всякого opencl и даже без шейдеров. Иксы могут при неудобных для них вызовах легко упереться даже в мощный проц - они умеют дофига всего и ряд операций довольно ресурсоемкие. Если их нескромно подергать - иксы могут встрять. И вся графика встрянет. Одна неважно написанная программа может заклинить всю графику. В ведроиде с его примитивным surface flinger все это сильно сложнее: время на рендеринг как я понимаю приписывается программе которая его вызывает, а не единственному общесистемному мега-рендереру. Так что с этой частью арбитража ресурсов и сохранния стабильности у андроида и прочих пожалуй можно еще и поучиться.
А с opencl и шейдерами чуть иная история: там изначально вообще никто не заморачивался арбитражем ресурсов. В открытом драйвере от амд одно время был вообще суровый лулз: однажды при старте одной игры у меня упал амдшный драйвер, с чем-то типа "can't allocate IB", или как там его, при том на ровном месте - игра даже рендерить толком ничего не начала. Почесав репу я нашел логи всего этого. И достаточно вербозный лог игры, и лог отвала драйвера. Найдя причастного игродела я поинтересовался - а что за фигня: зачем ты столько VRAM аллокатишь? (гигабайты!!!) Ответ был банален: игродел, оказывается, просто проверял в своем коде - а сколько VRAM в этой системе вообще потенциально могут дать под текстуры, чтобы знать на какой уровень качества по дефолту ему ориентироваться. Он аллокатил до тех пор пока не начинались ошибки и делал выводы. Как оказалось, амдшники на такой подход не рассчитывали чуть менее чем никак. И вообще не проверяли - могут ли они выдать кусок VRAM такого размера, хотя-бы чисто теоретически. Выделение памяти обламывалось. И далеко не только у обнаглевшей программы, после этого начинало заваливаться вообще везде. В конце концов - коллапсировало все что вообще могло, VRAM не оставалось на внутренние нужды и в конце концов издыхал драйвер, когда он не мог выкроить IB вообще ни на какие дальнейшие операции, а т.к. IB используются на каждый пшик - графика дохла в ноль. Подофигев с такого расклада - я отловил кого-то из амдшников толи в ирц, толи где-то на форониксе и обрисовал им вопиющий масштаб этого п-ца, т.к. по сути любая GLная программа может убить графику в системе в ноль буквально парой нехитрых действий. Понятное дело что они это в темпе вальса починили свое добро.
Но это присказка. А сказка в том что с планировкой инструкций GPU как я понимаю по прежнему "почти никак". В том плане что никакого особого арбитража там просто нет. В последнее время до AMD по мере развития вычислений вроде стало доходить что такой однозадачный игрориентированный подход, когда одна игра считает на всю, а остальное хоть умри - в современном мире уже "не очень". Они сделали виртуальную памяти и даже какие-то зачатки виртуальных машин (в самых новых GPU).
...ну в общем еще 3-5 поколений GPU и они прийдут к чему-то типа Xeon Phi с своей операционкой и нормальным шедулером задач, только эволюция с другой стороны :).
> Так 20MB RAM! (vs 130MB RAM у андроида) -
Ну так ява - известный memory hog. А кстати GPUшный резерв памяти в эти 120М входит или счтиается отдельно? А то у ведроидных девайсов GPU примитивный и без своей памяти - кусок отрубается от системной памяти, как в десктопном интеграте примерно.
> библиотеками ест меньше, чем покоцаный android. Применив яву, они просто перечеркнули
> весь проделанный труд по оптимизации потребления памяти системой.Ну да. Странные люди. В результате юзеры ведроида чертыхаются и заряжают каждый день. Гугл уже и сам наверное не рад что в яву вляпался. Их и судили, и возни по борьбе с ломовым потреблением ресурсов немеряно. Они вон дошли до чего-то типа предкомпиляции уже. Ну и нафига тогда надо было делать это java-only? Чудаки. Мне такой layering системы не нравится.
> mpv hd h264 - 10-12% cpu (программно декодирование) + 1% Xorg
Это при -vo opengl? Ну еще бы - там иксы почти не у дел :). А вы через иксовые методы вывода попробуйте - тогда и узнаете как в иксах с выводом больших битмапов "на скорость" через их протокол. Особенно если всякие читы типа shared memory (оно ж не прозрачное по сети) не использовать - вот тогда будет самое оно. А апликушникам, конечно, очень надо - долбаться с кучей опциональных расширений вместо того чтобы просто картинку рисовать, ага...
> hd6770 открытый драйвер (glamor) - есть тиринг в оконном режиме (окно растянуто
> почти на весь экран), в полноэкранном режиме нет тиринга.Ну вот я о чем. А в нормальном виде должен быть просто быстрый вывод картинки, с частотой как минимум вплоть до рефреша панели, без артефактов, во всех позах. А тут 5 лет бодались а все-равно местами вылазит.
У меня с -vo opengl я таки вижу тиринг на R9 270. Вот с vdpau - тиринга почти нет, но пару раз его можно узреть, если знать что ищешь (нагрузка на проц - около ноля).
> intel sna - тиринга как такового нет, но на специальном тесте (постоянно
> движущийся вертикальная белая полоса) есть ели заметные искажения в самом верху,
> возникающие на одном кадре раз в несколько (3-5) секунд.Да на самом деле все что касается синхронизации с vblank в драйверах пилят черт знает сколько. Но в целом оно пока работает по принципу лотереи. И чтобы не видеть мерцающие полосы посреди картинки, приходится прыгать с бубном подбирая через какой же вывод видео оно не будет проц клинить и артефачить. Мне кажется что на самом деле это должно работать как-то получше, а? :)
> Однако, с иксами вполне реально нарваться на тот факт что при
> большом потоке запросов от какой-то программы сами иксы упрутся в полку
> по CPU, обрабатывая запросы от программы.
> А вот с рендерингом битмапов у иксов в плане скорости
> всегда было "не очень".Вроде после прихода pixman нормально стало.
> В иксы никто не хочет соваться лишний раз, как в помойную
> яму. И многие спят и видят чтобы избавиться от них и
> перейти на что-то менее проблемное, типа вяленда какого. Это, заметим, сами
> разработчики так к иксам относятся.Скорее не хотят ломать совместимость и тянут кучу legacy. Сам wayland по ходу будет не проще - уже тянет libinput который тянет не отключаемый мультитоуч. Я вот ждал wayland, но чем ближе он к внедрению, тем больше у меня подозрений, что останусь я на иксах.
>> Видел подобное только когда рендеринг (на opencl) жестоко перегружал gpu.
> На самом деле достаточно 1 неудачно написанной программы - и оно так
> станет без всякого opencl и даже без шейдеров. Иксы могут при
> неудобных для них вызовах легко упереться даже в мощный проц -
> они умеют дофига всего и ряд операций довольно ресурсоемкие.Пример программы? С gtkperf тоже не тормозит.
> А кстати GPUшный резерв памяти в эти 120М входит или счтиается отдельно?
Нет его я не считал. Это уже проблема железа. От os это не зависит.
>> mpv hd h264 - 10-12% cpu (программно декодирование) + 1% Xorg
> Это при -vo opengl? Ну еще бы - там иксы почти не
> у дел :). А вы через иксовые методы вывода попробуйте -
> тогда и узнаете как в иксах с выводом больших битмапов "на
> скорость" через их протокол.С "-vo xv" 0.6% Xorg
> Ну вот я о чем. А в нормальном виде должен быть просто
> быстрый вывод картинки, с частотой как минимум вплоть до рефреша панели,
> без артефактов, во всех позах. А тут 5 лет бодались а
> все-равно местами вылазит.У них там есть какие-то новый настройки для тиринга, но я не пробовал - почти всегда в fullscreen смотрю.
> Мне кажется что на самом деле
> это должно работать как-то получше, а? :)Должно :) Но не всегда хватает времени и знаний починить или даже нормальный багрепорт написать.
> Вроде после прихода pixman нормально стало.Не ощутил как-то. Почему-то программы, которые явно не вкостылили две дюжины костылей - порядком тормозят по сей день. А на каком месте апликушники, пишущие кроссплатформенный софт вертели идею сильно прыгать под причуды одной конкретной графической подсистемы со всеми ее архаизмами и бестолковостями, задействуя опциональные расширения и прочая - легко догадаться. Поэтому работает оно в целом погано на мой вкус. Мной иксы классифицируются как "проблемный системный компонент, который желательно заменить".
> Скорее не хотят ломать совместимость и тянут кучу legacy.
И это все прекрасно, но времена VGA адаптеров закончились а требования к графике у юзерей стали совсем другие. Вон даже Khronos это просек. И да, их новый vulkan таки будет не совместим с OpenGL. Зато он будет таким каким его хотят видеть те кто им пользоваться будет. Т.е. производители GPU и игроделы которым потом под это писать. Истошная борьба с API деланными под совсем иные реалии всех задолбала. В играх особенно злобно т.к. там активный вывод графики и куча вычислений - "их всё".
> Сам wayland по ходу будет не проще - уже тянет libinput
Ну я не против какой-никакой стандартизации input-а самой по себе. Без этого как-то тяжко.
> который тянет не отключаемый мультитоуч.
А это чем-то плохо? В смысле, оно весит сильно много, или чего? Или из каких соображений это надо отключать? Чтобы потом было побольше боли пониже спины при желании сваять какой-нибудь девайс с интерфейсов в который можно тыкать пальцем? Или что это дает, кроме шанса получить граблиной в лоб лишний раз?
> тем больше у меня подозрений, что останусь я на иксах.
Это как бы дело хозяйское. Но подозреваю что майнтайнить их вам однажды придется самому. Т.к. желающих в этом копаться нынче днем с огнем не найдешь. Это куча легаси, с кучей проблем производительности и секурити. Иметь дело с этим мало кто хочет.
> Пример программы?
Так сходу не вспомню. Как вы понимаете, я такие программы как правило предпочитаю на всякий пожарный сносить. Т.к. перспектива вызвать на десктопе клин графики до состояния когда я не могу задачу прибить за время которое меня не напрягает - не айс. Но прецеденты были и мне это не понравилось.
> С gtkperf тоже не тормозит.
Подозреваю что он основное время проводит в либе gtk, а не иксах. Т.к. цель по идее проверить производительность gtk. И, соответственно, это время больше приписывается таки процессу gtkperf-а? Общий смысл предъявы - такой что у иксов есть какие-то довольно дорогие вызовы. И если программа будет их агрессивно использовать - иксы могут начать трескать 100% проца, уперевшись по производительности в 1 ядро CPU. В результате может начать вся графика, system-wide. Вплоть до сложности отрисовки манагера задач или терминалки, что как-то не очень то айс. Поэтому со своей стороны я предпочту чтобы графическая подсистема как таковая не занималась сложным рендерингом и прочими вещами на которых можно надолго встрять. С точки зрения стабильности работы системы и отсутствия клинов.
> Нет его я не считал. Это уже проблема железа. От os это не зависит.
Вот это очень спорное утверждение. По факту это между железом и софтом. И софт вполне может быть в курсе как оно и даже рулить этим (как минимум, драйвер). У всяких APU и интеграта как я понимаю драйвер явно в курсе какой регион используется как "типа, VRAM" и это потенциально может быть использовано для zero-copy оптимизаций. Ну и остальным программам эта память под общие нужды недоступна, так что логично ее считать занятой, наверное. И это один из недостатков интеграта: оно не только откусывает память, но еще и нефиговый бандвиз по шине пихает. Как минимум для долбежа на экран силами CRTC.
...а тем временем AMDшники козыряют 4096-битной (!!!!) шиной памяти.
> С "-vo xv" 0.6% Xorg
Вот только xv - опционльное расширение. И далеко не любая программа в курсе об этом. А если программа не в курсе явно - будет намного менее привлекательное слайдшоу. А когда кто-то пишет программу - последнее что он хочет это прокостыливать это древнее дepьмецо. Я считаю что графическая система должна быстро работать по дефолту, а не как тридевятая опция при пятом приседании в позу лотоса програмером.
> У них там есть какие-то новый настройки для тиринга, но я не
> пробовал - почти всегда в fullscreen смотрю.Фокус в том что это - одна из вещей которые по хорошему должны просто работать и вообще не кушать никому мозг. Ну примерно так же как я не хочу заниматься калибровкой датчика мыши под конкретно вот эту вот поверхность стола. Если мышь плохо катается - я таки буду считать что эта мышь - хреновая, а не то что мне надо присесть и сделать калибровку, использовать специальный коврик и прочая. И при удобном случае отделаюсь от столь проблемного экспоната в пользу менее проблемного без всяких сожалений.
>> это должно работать как-то получше, а? :)
> Должно :) Но не всегда хватает времени и знаний починить или даже
> нормальный багрепорт написать.Да там с всем этим vblank месиво какое-то. Возможна куча разных случаев (с композитором или без, etc). Драйвера не всегда идеально это обрабатывают, etc. Это периодически прокостыливают там и тут. Но реально сколько лет прошло, а работает как random(10).
А тут на пороге новые фичи стоят. Как то динамическая частота рефреша монитора. Ну то-есть если какой движок понял что зарендерить кадр за столько не судьба и будет дольше - он может и подольше, а его подождут. Минус тиринг, стало быть. Ну и потенциально меньше потребление энергии и бандвиз на шинах. Но фикус состоит в том что в линухе графический стэк к такому раскладу не готов чуть менее чем никак: там как я понял в куче мест допущения что FPS дисплея - нечто, буквально приколоченное гвоздями.
Скажи спасибо Линусу. Его же проблемы тивоизации не волновали. Получили с одной стороны убитый маемо, с другой напрочь тивоизированные железки. А после захвата рынка можно удавочку и ослабить - снимайте локи, рутуйте, делайте что хотите. гну/линукс уже не выберется.
Есть некоторое подозрение, что иначе там была бы какая-нибудь переписанная FreeBSD (а скорее - десяток таких переписанных).А насчёт "не выберется"... Поглядим. Я чем дальше, чем больше подозреваю, что платформа, где пользователь не доверяет софту, удобной быть не может в принципе. А закрытому софту доверять затруднительно - в основном потому, что каждая первая собака пытается делать что-то ещё кроме заявленных функций. Поэтому есть шанс, что выстрелит что-то удобное, что by design не будет поддерживать закрытый софт.
> Есть некоторое подозрение, что иначе там была бы какая-нибудь переписанная FreeBSD (а
> скорее - десяток таких переписанных).При том с паршивой овцы - хоть шерсти клок. Ну или нормальную поддержку SoC.
> уже проиграл войну за десктопы, теперь он проигрывает новую войну эмбедовкам
> новой школы. Взгляните на некоторые новые анонсы: телеки с ютюбом на
> Firefox OS, микроволновки с OpenCV на Андройде.И что характерно - все это таки разновидности ... линукса. Потому что Linux - это вообще только ядро :)
> 20 назад, а их тащут потому что боятся сломать совместимость,
Ну вон там всякие вяленды и миры есть. Как раз вот поэтому. А ломать совместимость - таки нехорошо. Потому что софт под ведроид - это круто. Но для десктопов напрочь не годится. Ну или попробуй в ведроиде хотя-бы чертеж сделать в CAD-е. И как, хорошо получается? А может, музычку сочинишь? Или киношку отредактируешь? Ах, ведроид оказывается только для потребления хорош? Ну вот поэтому и таскают иксы - 10 000 тормозливых калькуляторов и секундомеров с рекламой на обычных компьютерах не очень нужны.
> а Ульрих тащит свое glibc,
Ульрих давно ушел работать в банк.... ;)
> который в 10 раз жирнее новенького мусла,
Ну и умеет соответственно зело поболее, и оптимизирован местами получше. Поэтому там где место не жмет - вариант. Но в openwrt, когда на все и вся флеха 4 мега размером - придется таки пожертвовать фичностью.
> Musl тут конечно не панацея, но неплохой такой шаг, чтобы это болото
> как-то расшевелить.И шаг сделал дистр ориентированный на совсем-эмбедовку. Просто потому что uclibc был еще более обрубленый и еще более проблемный. А полновесный glibc для 4Мб флехи - таки не то...
> Не, простым пользователям на роутере не нужен pg. И нужен офис, виртуализация и джавва!Не сцы, coming soon. Спроси у гугля про banana pi router - они таки распаяли 2-ядерник на гигагерц и гиг памяти рядом с гигабитным свичом :)
>гугля про banana pi router - они таки распаялиЭто не роутер с *пользователями*. Это очередной развод самодельщиков.
> Это не роутер с *пользователями*.Пользователей на это можно навесить довольно прилично.
> Это очередной развод самодельщиков.
Ну я пожалуй разведусь, ибо достаточно мощная сетевая железка, где я контролирую и boot sequence и ОС - штука полезная, как ни крути. Да и ресурсов навалом по сравнению с обычными магазинными мыльницами. Где не забывают заявить вайфай на 100500 мегабитов но зато забывают сделать ресурсы на его обслуживание.
