iFone не имела прав на регистрацию марки iPhone, поскольку iFone и и iPhone — совсем разные по написанию слова.
Тогда и Apple не имела прав на регистрацию марки iPhone, поскольку Apple и iPhone — совсем разные по написанию слова.
Ваш вариант был предложен автором поста. Я лишь предложил замену одному из его вариантов, так как он выглядит более логичным — не надо указывать «public:»
Работаю над ААА игровыми проектами, где миллионы строк ООП кода. И чем больше я с ним работаю, тем больше ненавижу этот ООП. Считаю, что «С с классами» это золотая середина. Аскетичность С позволяет значительно увеличить читаемость кода. Не мне говорить о том, сколько времени мы проводим за чтением кода, особенно на проектах, которые пишут сотни программистов. В купе с некоторыми плюшками С++ так же помогает, к примеру шаблоны для контейнеров. В монструозных ООП системах невозможно понять флоу программы исключительно чтением кода -> обязательно необходимо запустить под отладчиком.
во-вторых, для этого случая: … то правильнее то же самое написать так:
class Foo
{
public:
static void foo();
};
...
Foo::foo();
тогда зачем там opengl часть вообще, можно выкинуть её и нормально замерять время.
по-моему это не принципиально. В обеих случаях ОГЛ часть будет отнимать одинаковое количество времени.
Все не ограничивается спрайтами. К примеру, если у тебя требование — OpenGL ES 1.1, то скининг мешей так же лучше делать на НЕОНе. Если множество низко полигональных объектов — их так же будет быстрее софтварно заинстансить, чем рисовать по одному.
Во-первых — это демо, а не реальный игровой проект.
У вас обсчёт их обсчёт (считаем спрайт как два треугольника) сьел 18-20% CPU.
Тогда попытайтесь нарисовать 10к динамичных спрайтов любым другим способом, к примеру по draw call'у на спрайт — боюсь, что в таком случае ваш фпс просядет раз в 10-20…
Всё таки не увидели в конце результата — на сколько это даёт прироста по филрейту.
Ровно на столько, на сколько мы освободили USSE от вершинного процессинга. Здесь замкнутый круг — если я буду сравнивать свой, так сказать, софтварный инстансинг с draw call'ом на спрайт — то я получу громадную разницу, но сравнение будет не объективным, так как при таком инстансинге я упираюсь именно в филлрейт, а при ДИПе на спрайт — в синхронизацию процессора с гпу. Так же, к сожалению, я не могу померить использование USSE на iOS девайсе — что бы знать, на сколько я освободил его от расчетов вершинных шейдеров. Это можно сделать имея не залоченное железо на Андроиде, Линуксе или Винде.
А увеличить кол-во поликов — и процессор будет только этим и занят, а надо ещё физику считать, и ещё отсекать от огромной сцены обьекты
Ну так современные девайсы имеют больше одного ядра — зачем же им простаивать-то?!
Вот у меня Nokia 3310 уже почти 10 лет, и меня все устраивает. Заряд держит почти неделю, в руке лежит удобно, все свои функции выполняет.
Купил за 100 долларов какой-то простой самсунг с батареей на 2Ач, заряд держит почти месяц. Раньше я забывал зарядить свой предыдущий телефон и меня постоянно злило то, что он оказывался разряженным в нужный момент. Теперь я с нетерпением жду, когда же этот разрядится :)
Дело в дата лэйауте. У меня помимо позиции на каждую вершину лежит и цвет. То есть прийдется писать специальную ф-цию для этого случая. Опять же, хорошее замечание. Я постараюсь в ближайшее время изменить код и посмотреть на результат. Соответственно, проапдейчу пост
Не все инструкции 128битные
Я сразу не уловил замечание про размер инструкций. Думал, разговор идет о размере SIMD регистров.
Замечание учтено. Спасибо.
SGX543 это следующее поколение — USSE2, который обрабатывает 2 x FP32
К сожалению мне не удалось найти какой либо официальной информации на этот счет. Потому взял профайлер шейдеров, посмотрел на количество циклов с 535-м компилятором и 543-м. Получилось одно и то же. С чего я и сделал соответствующий вывод. Если вы сможете дать достоверную, подтвержденную информацию на этот счет — буду очень благодарен. Пока я оставлю статью так, как она есть.
C какого испуга USSE выполняет лишь 1 флоат операцию? Или речь идёт про пайп а не про ядро?
USSE обрабатывает 32-х! битные флоаты на скалярном процессоре. Если флоаты 16-ти битные — тогда они выполняются на векторном движке. Это описано где-то в мануалах от Imagination. В Rogue этот недостаток будет исправлен. На этом делается акцент в спецификации OpenGL ES 3.0
У A9 есть аппаратный префетч (на несколько стримов)
У А8, который как раз в моем iPod Touch 4, нету апаратного прифетча
>А как поведет себя cblas не смотрели?
Нет. Я даже не в курсе, что это. Быстро погуглил, пробежался по коду — не заметил там никакой векторизации. Так что этот будет выполняться на FPU и даст соответствующий результат…
Самым быстрым оказались интринсики. GLKMath — это просто узкоспециализировання библиотека с векторизированным кодом. Шаг в сторону — и прийдется писать самому. Я здесь её больше привел для сравнения и что бы показать, что новый Clang очень хорошо оптимизирует код. GCC 4.2 жутко сливал в этой задаче и на нем GLKMath давал крошечный прирост.
>почему ручной ассемблер такой неприлично медленный получился.
Компилятор лучше меня знает все о инструкциях — количество циклов, какие могут застоллить пайплайн, как лучше их перетасовать, что бы избежать столлов, как протолкнуть данные в регистры и из регистров — VFP и NEON разделяют между собой набор регистров. Вот и компилятор в асм листинге для интринсиков протаскивал некоторые данные через VFP регистры.
К тому же я не специалист по ассемблеру. Возможно, что кто-то более опытный, сразу заметит косяки в моем асме.
>Я думал, у вас под рукой есть
Тоже нету — я сейчас не за маком
Асм листинг :) Но я решил его не вставлять сюда — это нужно далеко не всем, тем кому это действительно надо не составит труда самому заглянуть в листинг — ссылка на проект в самом низу. Плюс ко всему статья и так обьемная получилась, около 8-ми страниц А4.
Тогда и Apple не имела прав на регистрацию марки iPhone, поскольку Apple и iPhone — совсем разные по написанию слова.
во-вторых, для этого случая:
… то правильнее то же самое написать так:
ИМХО, лучше писать так:
по-моему это не принципиально. В обеих случаях ОГЛ часть будет отнимать одинаковое количество времени.
Да. Вот этот телефон — www.mobile-review.com/review/samsung-e2370.shtml
Результат изменился не значительно — было 5300, стало 4780, прирост — около 10%. Пытался перетасовать стор инструкции — особой разницы не заметил.
У вас обсчёт их обсчёт (считаем спрайт как два треугольника) сьел 18-20% CPU.
Тогда попытайтесь нарисовать 10к динамичных спрайтов любым другим способом, к примеру по draw call'у на спрайт — боюсь, что в таком случае ваш фпс просядет раз в 10-20…
Всё таки не увидели в конце результата — на сколько это даёт прироста по филрейту.
Ровно на столько, на сколько мы освободили USSE от вершинного процессинга. Здесь замкнутый круг — если я буду сравнивать свой, так сказать, софтварный инстансинг с draw call'ом на спрайт — то я получу громадную разницу, но сравнение будет не объективным, так как при таком инстансинге я упираюсь именно в филлрейт, а при ДИПе на спрайт — в синхронизацию процессора с гпу. Так же, к сожалению, я не могу померить использование USSE на iOS девайсе — что бы знать, на сколько я освободил его от расчетов вершинных шейдеров. Это можно сделать имея не залоченное железо на Андроиде, Линуксе или Винде.
А увеличить кол-во поликов — и процессор будет только этим и занят, а надо ещё физику считать, и ещё отсекать от огромной сцены обьекты
Ну так современные девайсы имеют больше одного ядра — зачем же им простаивать-то?!
Купил за 100 долларов какой-то простой самсунг с батареей на 2Ач, заряд держит почти месяц. Раньше я забывал зарядить свой предыдущий телефон и меня постоянно злило то, что он оказывался разряженным в нужный момент. Теперь я с нетерпением жду, когда же этот разрядится :)
Я сразу не уловил замечание про размер инструкций. Думал, разговор идет о размере SIMD регистров.
Замечание учтено. Спасибо.
SGX543 это следующее поколение — USSE2, который обрабатывает 2 x FP32
К сожалению мне не удалось найти какой либо официальной информации на этот счет. Потому взял профайлер шейдеров, посмотрел на количество циклов с 535-м компилятором и 543-м. Получилось одно и то же. С чего я и сделал соответствующий вывод. Если вы сможете дать достоверную, подтвержденную информацию на этот счет — буду очень благодарен. Пока я оставлю статью так, как она есть.
Я НЕ перечитываю матрицу из памяти. Я загружаю её в NEON регистры
Моя ошибка :(
NEON в Cortex-A9 64х битный и умеет обрабатывать только ДВА * 32-х битных флоата параллельно.
128-ми битный. Пруф — infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0409e/Chdceejc.html
C какого испуга USSE выполняет лишь 1 флоат операцию? Или речь идёт про пайп а не про ядро?
USSE обрабатывает 32-х! битные флоаты на скалярном процессоре. Если флоаты 16-ти битные — тогда они выполняются на векторном движке. Это описано где-то в мануалах от Imagination. В Rogue этот недостаток будет исправлен. На этом делается акцент в спецификации OpenGL ES 3.0
У A9 есть аппаратный префетч (на несколько стримов)
У А8, который как раз в моем iPod Touch 4, нету апаратного прифетча
Нет. Я даже не в курсе, что это. Быстро погуглил, пробежался по коду — не заметил там никакой векторизации. Так что этот будет выполняться на FPU и даст соответствующий результат…
Компилятор лучше меня знает все о инструкциях — количество циклов, какие могут застоллить пайплайн, как лучше их перетасовать, что бы избежать столлов, как протолкнуть данные в регистры и из регистров — VFP и NEON разделяют между собой набор регистров. Вот и компилятор в асм листинге для интринсиков протаскивал некоторые данные через VFP регистры.
К тому же я не специалист по ассемблеру. Возможно, что кто-то более опытный, сразу заметит косяки в моем асме.
>Я думал, у вас под рукой есть
Тоже нету — я сейчас не за маком