Apple Metal API: в чем же фишка?

[scipe]

Блин. Нет графиков. Не одного… :(

[Anastasia_K]

Держите.

Скрытый текст

Простите, не могла удержаться. уж очень «подробный» запрос :)

[mannaro]

Графиков возрастания скорости, я думаю =)

[Vlad_IT]

Я вижу большинству, и этот понравился :-)

[Vavius]

Интересная штучка. Большие игроки типа Unity3D или Unreal Engine и так поддерживают 3-5 разных графических API, добавить еще один им не сложно.

А так жалко конечно что опять все разное на всех платформах. С другой стороны, простые кроссплатформенные 2д движки могут ограничиться OpenGL и не париться особо. Сменить OpenGL на metal полностью еще не скоро станет возможным (на рынке полно старых девайсов), а поддерживать оба АПИ сложно и не факт что вообще что-то даст в плане производительности.

[dordzhiev]

Вот я не могу понять таких комментаторов (без обид). Кто принуждает вас использовать Metal? Пишите с OpenGL.
А про загадочных людей, поддерживающих оба апи — уже вопросы к ним. Видимо и деньги есть, и время есть.

[khovansky]

Эпики со своим Unreal Engine 4 уже. Точнее даже, к самому WWDC представили.

[Mairon]

Большие игроки типа Unity3D или Unreal Engine и так поддерживают 3-5 разных графических API, добавить еще один им не сложно

А производители движков от этих Metal/Mantle и иже с ним и есть главные победители. Если сейчас ещё и Qualcomm, ARM, NVIDIA и Intel (а ведь на Android ещё есть экзотичные Vivante и Broadcom) придумают по своему API, то будут два варианта:
а). Чтобы добиться высокой производительности свой движок под каждый из 5-7 «мобильных» API обычным разработчикам будет дорого поддерживать, поэтому проще лицензировать сторонние. Как следствие, Epic, Unity и прочие в большом профите, ибо без них будет вообще никуда, особенно для студий без поддержки зажиточных издателей.
б). Для консистенции пользовательского впечатления все продолжат использовать OpenGL ES. А то будет непорядок, если какой-нибудь Asphalt 10 от Gameloft на Samsung Galaxy S7 с Mali будет работать в 10 раз медленнее, чем на Galaxy S7 с Adreno, или наоборот, из-за того, что не осилили допилить движок под какой-нибудь специфический собственнический API.

Вообще интересно, как Google на это дело с Metal API отреагирует. Изобретёт свой велосипед по традиции с Renderscript Compute, или понесёт бабло в Khronos для ускорения проектирования и стандартизации OpenGL ES Next.

[Polsky]

Забавно, что на первых массовых ускорителях 3dfx тоже был минималистичный API Glide, с полным доступом к памяти ускорителя и командами, предельно близкими к железу. Потом всё пошло по пути усложнения API, и где-то на DirectX 7 с его T&L сложность API достигла пика и повернула обратно, сначала к шейдерам, потом к вычислениям на GPU, а теперь, сделав полный круг, вернулись к минимальному API. Прошло каких-то 18 лет.

[splav_asv]

Просто время программистов подешевело и железо опять стало узким местом. Вот и заставляют людей писать более низкоуровневый код.

[splav_asv]

В OpenGL ES 2.0+ и OpenGL Core Profile (3.0+) вообще нет вызовов glBegin(), так что вы уж учень утрируете либо сознательно привираете — уже никто не тащит обратную совместимость такого уровня. Fixed pipe остался в прошлом. В числе возможных кандидатов на включение в OpenGL 5 и ES 4 очень много расширений, уменьшаяющих количество вызовов API и нагрузку на CPU в целом. Так что OpenGL еще повоюет на этом поле.
Его проблема в другом, учитывая заточенность на конкретную архитектуру SoC, можно одновременно и сильно оптимизировать API и дать доступ к уникальным фишкам, вроде того же прямого доступа к памяти GPU, хотя AMD может быть тоже что-то подобное сделает для своих APU. Но скорее это будет для OpenCL или вычислительных шейдеров OpenGL, чем для задач GPU.

[Mercury13]

:)
Название как-то связано со старым добрым S3 MetaL или просто совпадение?

[MrShoor]

Есть нюанс и в заточке под A7 — благодаря ему Metal заточен под работу на системах с общей памятью, т.е. CPU и GPU могут получать прямой доступ к одним данным без необходимости перебрасывать их по шине PCI. Metal дает прямой доступ для программы к буферам из CPU, и ответственность за то, что эти данные не используются одновременно и GPU, ложится на плечи программиста. Эта полезная функция позволяет смешивать произведение вычислений на GPU и CPU.

Я думаю вам стоит поправить этот абзац. Иначе можно подумать, что если у нас какой-нибудь Core i7 с GPU на борту, то для старых API данные все равно идут по шине PCI (которого может даже не быть). Насколько я понял вся соль — в отсутсвии синхронизации доступа CPU/GPU, а не в «прямом» доступе. Ну и стало быть не важно лежит между GPU и системной памятью PCI или нет.

[kashey]

Эх, помню я время, когда каждую неделю с новым детонатором приходило по 5 новых NV_, а с каждым новым каталистом — пара, тройка ATI_ или EXT_
А еше через полгода мы все стирали и заменяли на ARB_…
Не надо мне такого счастья больше…