WWDC 2014: Metal - це дуже серйозно

Уважно вислухавши і прочитавши все, що було сказано і написано на металеву тему представниками 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 багато.