Рынок мобильных GPU

В этой теме обсуждаем все что относится к современным мобильным GPU:

-Ваши мнения о текущих GPU от ARM/Qualcomm/Imagination/nVidia достоинства и недостатки каждого?
-Будущее GPU для мобил, какие применения вы видите Graphics/OpenCL/Image Processing/AR
-Cloud computing и мобильные технологии?

Господа офицеры! Не могли бы вы в доступной форме, оперируя фактами, объяснить преимущества и недостатки всех современных мобильных GPU?
И заодно объясните мне, почему в GLBenchmark'е айпад2 набрал больше очков, чем айфон4с, хотя чип у них одинаковый, а разрешение экрана у айфона меньше на четверть?
Буду премного благодарен.

>> Господа офицеры! Не могли бы вы в доступной форме, оперируя фактами, объяснить преимущества и недостатки всех современных мобильных GPU?

это в названии темы.

>> И заодно объясните мне, почему в GLBenchmark'е айпад2 набрал больше очков, чем айфон4с, хотя чип у них одинаковый, а разрешение экрана у айфона меньше на четверть?

Первое что приходит на ум тактовая частота для Iphone снижена с целью экономии power.

>> тактовая частота для Iphone снижена с целью экономии power

А действительно. Погуглил, оказалось, что у 4с 800 Мгц, а у айпада 1000 Мгц. Спасибо.

Исходя из моего опыта работы с мобильными GPU самый большой скачок производительности будет когда добавят в архитектуру отдельную видеопамять. Потому что почти всегда я упираюсь в скорость передачи данных между cpu-gpu. А сдерживает производительность сейчас банальный вопрос энергопотребления. Мощную видеокарту уже сейчас могут запихнуть в корпус, а вот чтобы аккумулятор не садился за пол-часа игры - вот проблема.

Ну и для разработчика под это всё добро большими трудностями становится как раз многообразие производителей. Один функционал работает на одном устройстве, глючит на другом и совсем не работает на третьем. И это даже при использовании стандартных функций opengl, без разных специфический расширений.

alorken
> Исходя из моего опыта работы с мобильными GPU самый большой скачок
> производительности будет когда добавят в архитектуру отдельную видеопамять.
> Потому что почти всегда я упираюсь в скорость передачи данных между cpu-gpu.
А когда добавят отдельную видеопамять, то данные между цпу и гпу не придется передавать? Видимо, ты ошибся в первом сообщении.
Самый большой скачок производительности будет, когда на мобильниках перестанут выделять рам для гпу и дадут ему пользоваться тем же, что и ЦПУ + введут в АПИ\драйвер необходимый для этого функционал

StiX
Когда добавят видеопамять,  не придется КАЖДЫЙ раз перегонять данные. Это конечно касается только статических объектов и текстур.

А насчет второго твоего предложения - поясни, что имелось ввиду. Сейчас для мобилок то как раз для gpu ничего отдельно не выделяется.

alorken
> Когда добавят видеопамять, не придется КАЖДЫЙ раз перегонять данные.
это что за девайс у тебя такой?! О_о И куда тогда ты гоняешь данные с проца, если у гпу нет памяти и под него из рама ничего не выделяется?!

alorken
> А насчет второго твоего предложения - поясни, что имелось ввиду.
То и имелось. У тебя есть текстура в раме, ты дал драйверу на нее указатель и сказал: "Юзай текстуру с такими параметрами, она лежит по этому указателю" - все ништяк, драйвер ничего не копирует, не блокирует поток до завершения операции, все летает.
alorken
> Сейчас для мобилок то как раз для gpu ничего отдельно не выделяется.
Из рама девайса какая-то часть отдается гпу. Вышеприведенный пример на современных девайсах будет работать так:
Ты даешь указатель драйверу, а он, сука, берет копирует данные из одного адреса в раме в другой, блокируя при этом поток.

StiX
Я вообще про то, что часто gpu не успевает брать данные из обычной памяти, чтобы полностью себя загрузить. Вот если бы добавили отдельную более производительную память, это бы ускорило существенно графику.

alorken
Что-то тебя совсем не понять. Мне легко удавалось загрузить гпу по полной и при том держать утилизацию проца на уровне меньше чем 20%

alorken
> Вот если бы добавили отдельную более производительную память, это бы ускорило
> существенно графику.
Какую? Для чего? Будешь так же с проца копировать на "отдельную более производительную память" и в итоге получишь то, что и так имеешь сейчас - ненужную синхронизацию. Какая разница, откуда будет читать данные ГПУ, если он является частью SoC?! У Imagination для тайлов есть быстрая память на чипе.

StiX
Если шейдеры сложные, то можно конечно загрузить gpu. Но на простых медленная память давала о себе знать. Ну и потом я говорю о видеопамяти, которая была бы быстрее обычной. Тогда работать будет быстрее. Кстати, какого размера эта быстрая память у Imagination?

alorken
> Если шейдеры сложные, то можно конечно загрузить gpu.
На ЕС 1.1 тупо рисуя только спрайты (текстура и больше ничего), либо рисуя только геометрию

alorken
> Но на простых медленная память давала о себе знать.
Уже 3-й раз тебе повторяю - проблема не в памяти, а драйвере, который копирует данные туда-сюда. Под какой девайс писал?

alorken
> Кстати, какого размера эта быстрая память у Imagination?
Хз. Достаточного для того, что бы сохранить колорбуфер тайла

StiX
Не все драйвера копируют туда/сюда и проблема не только в этом, тут еще Blending и Z buffer.

  Проблема memory bandwidth остается большой проблемой до сих пор, именно поэтому люди возятся с гемором типа GMEM и tiled-renderer, интереснее становится с появлением DX11, когда большинство tiled-rendering approaches не работает. 
  Соглашусь что проблема скорее от недооптимизированого софта с большим количеством Z-read/write к примеру

les_paul
> Не все драйвера копируют туда/сюда
Ну так назви, где на мобильниках не копируют. Я уже 3-й раз спрашиваю про платформу, под которую ты писал, но ты упорно увиливаешь от ответа...

les_paul
> тут еще Blending и Z buffer.
Blending это операция
Z buffer это буфер. У Imagination он хранится на чипе (твоя отдельная более производительная память), так что у них выборка идет быстро, и это никак не тормозит блендинг

les_paul
> Проблема memory bandwidth остается большой проблемой до сих пор
Не такая уж и большая это проблема, особенно в сравнении с латентностью памяти, потому латентность всегда стремятся компенсировать за счет пропускной способности - претачи\префетчи всякие и т.д.

les_paul
> Соглашусь что проблема скорее от недооптимизированого софта с большим
> количеством Z-read/write к примеру
Проблема не в софте, а в отсутствии единой архитектуры (как на консолях), и что бы компенсировать эту разнородность драйвер несет в себе большой оверхед.

les_paul
> GMEM
что это такое?

les_paul
> интереснее становится с появлением DX11, когда большинство tiled-rendering
> approaches не работает.
Хм... Неужели десктопные ГПУ работают в режиме отличном от IMR?!

>>Ну так назви, где на мобильниках не копируют. Я уже 3-й раз спрашиваю про платформу, под которую ты писал, но ты упорно увиливаешь от ответа...

NDA . 100% available on latest drivers.
I never did any kind of mobile SOFTWARE development before, for any platforms. What I did is called GPU System Architecture.

>>Z buffer это буфер.

Thanks Captain!

>>У Imagination он хранится на чипе (твоя отдельная более производительная память), так что у них выборка идет быстро, и это никак не тормозит блендинг>:

The memory you are talking about called GMEM (Graphics Memory) and, yes, Z-Buffer tiles are stored there. The question is why do we have GMEM and tiled-rendering? And the answer would be because of memory bandwidth problems. It is big headache  for  driver developers  and architects to support tiled-rendering of any type.  Another problem about it that would be very hard to utilize this approach for  DX11/GS kind of things.

>>Хм... Неужели десктопные ГПУ работают в режиме отличном от IMR?!

We were talking about MOBILE GPUs, right?