WWDC 2014: Metal – это очень серьезно

4

Внимательно выслушав и прочитав все, что было сказано и написано на металлическую тему представителями Apple, лучшие из аналитиков пришли к единственно правильному выводу: Metal для iOS 8 и Apple A7 – это разведка боем. Что-то значительно более важное не заставит себя ждать. Apple решила взять под свой полный контроль еще одно тонкое место во всех её системах, тщательно взвесив все “за” и “против”. Уровень секретности был таким же, как при Стиве: не случилось ни одной утечки. Затея была очень рискованной.

Согласятся ли компании разрабатывающие программы зависящие от OpenGL и/или OpenCL для разных платформ, включая iOS и OS X? Некоторые из этих программ были очень важны для Apple. Доля Apple в доходах этих компаний хоть и была существенной, но её потеря их существованию не угрожала.

Что они предпочтут: тратить деньги на разработку в нестандартных API или потерять часть дохода? Пока не попробуешь – не узнаешь. И лучше всего двигаться к этому потихоньку, чтобы можно было вовремя притормозить, если что-то пойдет не так.

В 2014 не все согласились с лучшими из аналитиков. Многие не воспринимали это всерьез. Более важное случилось в июне 2018 года – но это пока не наша тема.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D.

Кризис

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

Производительность графических процессоров (GPU), год за годом, росла значительно быстрее чем производительность центральных процессоров (CPU) – отвечающих за все. В итоге, в отношениях между CPU и GPU сложилась революционная ситуация: верхи не могли (справиться), низы не хотели (думать самостоятельно, потому что не могли).

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

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

Графическая мощь требовалась и серьезным специалистам, но сколько их таких?

К середине первого десятилетия XXI века центральные процессоры (CPU) уже не могли в полной мере использовать мощь GPU. С такой же проблемой столкнулись авиационные оружейники когда сверхзвуковые скорости стали обычным явлением – все происходило настолько быстро что экипаж физически не успевал оценить обстановку и прицелиться.

Теперь в роли людей оказались CPU. Теперь они не могли одновременно “пилотировать” логику игры, готовить и проверять запредельно точные команды и отображать результаты на экране.

Приплыли?

Метод Apple

Если вы хотели бы узнать почему изделия Apple, несмотря на огромные числа на их ценниках, почти не обращая внимание на странные ограничения и непонятные запреты (только ворча и плюясь) почти всегда имеют успех, пограничный конфликт между CPU и GPU проявил этот секрет яснее чем что-либо другое.

Что-то вроде этого они делают постоянно, это суть их метода.

Первый Mac был абсолютно невозможен: у него были неплохие тактико-технические характеристики для своего времени, но только на реализацию главной его “фишки” – того самого графического пользовательского интерфейса – их требовалось в разы больше чем у него было.

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

Первый iPhone был абсолютно невозможен, но они его сделали, таким же способом.

Использовать мощь GPU хотя бы наполовину было невозможно, но они научились делать это. Отношения CPU и GPU – невероятно сложная область человеческого знания. Потоки, конвейеры, шейдеры, ускорители, рендеринг – об этом написано множество толстых книг, перед прочтением которых нужно прочитать много-много других книг, а чтобы понять их…

Но то как они это сделали раскрывает суть их метода ярче и понятнее чем всё остальное.

Диагноз

Взаимодействием между CPU и GPU занимался “переводчик”, действия которого были далеки от оптимальных. Переводчиком был OpenGL. Язык, которому в 2014 было уже 25 лет (как WWDC по версии Apple), универсальный, поддерживающий все достойные этого платформы и все заслуживающие этого графические процессоры – от новейших с их почти термоядерной мощью до самых архаичных, из прошлого тысячелетия.

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

Совместимость упрощает распространение графических решений между платформами. И это тоже важно, с коммерческой точки зрения это едва ли не второй по важности аспект.

Естественно, OpenGL не был оптимален ни на одной из платформ где он использовался, он был компромиссным решением. То есть, тем самым “тонким местом”, где хронический по своей сути конфликт обострялся и наносил ощутимый ущерб.

Для большей ясности (которая, как говорил настоящий Мюллер, одна из форм полного тумана), исследуем взаимодействие CPU с GPU на примере типичной “стрелялки”. Игра – это какая-то логика, герои с какими-то свойствами, ландшафт, оружие и тому подобные виртуальные реалии. Это область отвественности CPU.

В каждую единицу времени (раз 30..60 в секунду) текущая игровая ситуация должна отображаться на экране. На самом последнем этапе отображением занимается GPU, но в силу своей тупости он нуждается в абсолютно точных и предельно подробных указаниях.

Эти указания готовит CPU. OpenGL, каждый раз заново, должен отрисовать все объекты которые должны появиться на экране. Указать их “физические” свойства (цвет, материал), определиться с источником или источниками света, перепроверить “шейдеры” (небольшие функции выполняемые GPU) управляющие тенями, отражениями и массой других вещей, и возможно, преобразовать их исходные коды в команды для GPU.

В том что все это делается снова и снова, есть смысл. Если поддерживаются платформы с самыми разными “странностями”, графические процессоры с разными возможностями.

1/30 секунды для современных CPU – это уйма времени. Но даже в сильно сокращенном виде комплекс действий по отрисовке единственного экрана впечатляет. На самом деле от CPU требуется на порядок или два больше действий. Результат: GPU терпеливо ждет, пока CPU подготовит все что нужно, стремительно исполняет новые указания, и снова ждет.

1/30 секунды часто оказывается недостаточно. Игра тормозит, хотя GPU самый-самый, на котором можно было бы кипятить чайники (если бы не системы охлаждения).

Рецепт от Apple (“варим” Metal)

Во-первых, нужно сконцентрироваться на одном-единственном GPU. На том который встроен в Apple A7, PowerVR G6430 в 4-кластерной конфигурации. На острие главного удара. Остальное (пока) игнорируем.

Во-вторых, пишем “переводчика” с чистого листа, как если бы никаких OpenGL никогда не было (но отлично помним обо всем, чего хотелось бы избежать).

Поскольку мы в точности знаем сильные и слабые стороны единственного графического процессора который нужно поддерживать, учитываем только их.

В-третьих, все что только можно выносим за скобки конкретного обращения к GPU, и по возможности, готовим заранее все шейдеры, физические свойства, элементы композиции.

Это если коротко.

И на этом месте Стив сказал бы “бум” – в некоторых случаях производительность связки CPU и GPU вырастала в 10 раз. Правда никто и ни разу не продемонстрировал подобные случаи, но ускорение в 5-6 раз случалось сплошь и рядом.

Ну приврали (слегка) маркетологи, у них работа такая.

Выросла не только скорость – у CPU появилась масса дополнительного времени, которое можно было потратить на логику игры, на увеличение числа героев, на больший реализм происходящего.

На WWDC 2014 показали Zen Garden. На Apple A7, если использовать общепринятый OpenGL, показанное было бы абсолютно нереально.

И все это только для Apple A7 c PowerVR G6430 в 4-кластерной конфигурации? Не похоже ли это на абсолютную и непростительную глупость, за которую всем (даже непричастным) не может не быть стыдно?

Нет. Те, кто хорошо разбирался в этой области, уже в июне 2014 года предсказали то, что случилось через четыре года.

Это было только начало. Metal смог заменить OpenGL (и ни в чем не виноватый OpenCL, который просто попал под руку) сначала в одной конкретной комбинации (iOS 8 и Apple A7), затем в еще одной, затем…

Другие причины создания Metal

Даже если бы Apple несла ущерб от неспособности OpenGL качественно выполнять его долг до 2009 или 2010 года, отказываться от него Apple не стала бы. Это было бы ошибкой, которая могла обернуться гибелью компании.

До мобильной революции Apple слишком сильно зависела от готовности разработчиков со стороны переносить известные на более распространенных платформах программы в OS X.

Теперь компания одним из лидеров рынка мобильных устройств, временами абсолютным лидером.

А успех с организацией разработки собственных процессоров (CPU и систем-на-чипе с их участием) добавил им уверенности в себе.

И кроме всего прочего, если вы еще не пробовали программировать в Metal – попробуйте! Это очень красиво. OpenGL на фоне Metal выглядит как биржевые сводки за прошлый год на фоне блестящей захватывающей прозы.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате. Там и про Metal много.

Лучший комментарий

 
Авторизуйтесь Чтобы оставить комментарий