> Так у андроида не лучше - запустите самый примитивный секундомер и посмотрите 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 в драйверах пилят черт знает сколько. Но в целом оно пока работает по принципу лотереи. И чтобы не видеть мерцающие полосы посреди картинки, приходится прыгать с бубном подбирая через какой же вывод видео оно не будет проц клинить и артефачить. Мне кажется что на самом деле это должно работать как-то получше, а? :)
