Apple metal 2: Metal Overview — Apple Developer

macOS High Sierra приносит Metal 2, поддержку VR и другие новшества

в чем же фишка? / Хабр

На WWDC 2014 всех нас ждал сюрприз: анонс нового графического 3D API под названием Metal. Но на этот раз мы имеем дело не с новым высокоуровневым API поверх OpenGL ES (как было в случае с Scene Kit), а с новым низкоуровневым API для рендеринга и вычислений, которое может служить заменой OpenGL в играх. По словам Apple, Metal может быть до 10 раз быстрее, чем OpenGL ES (точнее говоря — может генерировать вызовы отрисовки [draw calls; передача данных на GPU] в 10 раз быстрее) и доступен только на устройствах с iOS и процессором последнего поколения A7.

Этот анонс спровоцировал новую волну обсуждения и споров насчет необходимости появления новых графических API, которые должны (или не должны — кто знает) заменить OpenGL. Предлагаемый вашему вниманию пост не намерен участвовать в этой дискуссии – его целью является разъяснение того, чем все-таки Metal отличается от OpenGL ES, чьей заменой он является. Чтобы понять, что такого особенного (или же наоборот, ничего особенного) есть в Metal API, нам придется немного заглянуть под «капот» графических API и GPU.

Как работают GPU и графические API

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

Для простого улучшения в работе GPU этот процесс стоит запустить асинхронно; тогда GPU не будет блокировать CPU и вызовы API будут возвращать результат почти мгновенно. В этом случае GPU возможно не будет использоваться на все 100%, поскольку ему возможно придется ждать от CPU новых вызовов рендеринга (= начала кадра), в то время как вызовы остальных команд будут ждать завершения предыдущих. Это становится причиной того, почему большинство графических драйверов собирают все вызовы отрисовки (и другие задачи, которые нужно будет выполнить на GPU — например, изменение состояний) для отрисовки всего кадра перед отправкой его на GPU. Эти буферизованные команды будут затем отосланы обратно после того, как будет получена команда для отрисовки следующего кадра, благодаря чему GPU будет использоваться настолько эффективно, насколько это возможно. Конечно, это добавит один кадр задержки: пока CPU будет создавать задание для текущего фрейма, прошлый фрейм будет рендериться на GPU. На самом деле, можно буферизовать больше одного кадра и таким образом добиваться большей частоты смены кадров — за счет еще большей задержки.

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

Итак, мы узнали как минимум две важные вещи о том, что происходит за сценой совместной работы OpenGL с современными GPU: изменение состояний может быть сложным, если требуется новая комбинация состояний и все операции на GPU будут задержаны на некоторое количество времени.

В приложении, один поток актуальных команд для одного кадра, которые надо выполнить на GPU, формируется и отправляется на GPU сразу весь за один раз (на самом деле все немного сложнее, но давайте не будет пока углубляться).

Подробнее прочитать о том, как работает современный пайплайн компьютерной графики вы можете в серии статей Fabian Giesens — “A trip down the Graphics Pipeline“.

Почему у другой программной модели могут быть преимущества

Как вы уже увидели, от программиста спрятано огромное количество сложностей и хитрых трюков (их наверняка еще больше, чем я упомянул), которые прячут то, что непосредственно происходит. Одни из них делают жизнь простого разработчика проще, другие — заставляют его искать способы обхитрить драйвер или «копать» в сторону побочных эффектов работы вызовов API.

Некоторые графические API сегодня пытаются убрать большую часть этих трюков, раскрывая скрываемую ими «запутанность» – и в некоторых случаях оставляя на волю программы решение всех связанных проблем. В этом направлении шли графические API PS3, в нем же идет AMD со своим Mantle, туда же собираются грядущие DirectX 12 и Apple Metal.

Что же изменилось?

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

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

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

Другой плюс от нового API в том, что оно не обязано нести груз совместимости с предыдущими версиями и поэтому не будет таким консервативным.

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

И как это в 10 раз быстрее?

Каждый вызов отрисовки стоит сколько-то времени на CPU и сколько-то времени на GPU. Metal API уменьшает время, затрачиваемое CPU, благодаря упрощению контроля за состояниями и благодаря этому уменьшению числу проверок на ошибки от драйвера на правильность комбинаций состояний. Еще помогает предварительное вычисление состояний: можно не просто выполнять проверку на ошибки во время билда, но и само изменения состояния потребует меньшее количество вызовов API. Возможность параллельного построения буферов команд еще больше увеличивает число вызовов отрисовки в том случае, если приложение привязано к CPU.

А вот рендеринг на GPU с другой стороны быстрее не становится, приложение которое делает совсем немного вызовов отрисовки для больших мешей (меш — часть модели, состоящая из вершин объекта] не получит никакого преимущества от перехода на Metal.

Может ли то же самое быть сделано на OpenGL?

На GDC 14 была отличная презентация “Approaching Zero Driver Overhead” за авторством Cass Everitt, John McDonald, Graham Sellers и Tim Foley. Основной ее идеей было уменьшение работы драйвера в OpenGL при помощи увеличения количества работы, производимым вызовов отрисовки, и использованием новых объектов GL и меньшего количества числа вызовов GL для повышения эффективности.

Эта и другие идеи потребуют дальнейшего расширения OpenGL и появления новых версий этого API, но многое из этого можно будет перенести в OpenGL ES. Что мы потеряем — так это возможность прямого управления командными буферами, со всеми своими «за» и «против».

Какова вероятность увидеть это в будущем? Из-за поддержки обратной совместимости, остается надеяться только на появление некоего набора функций, который можно будет назвать «современное ядро», но и его скорее всего придется сделать совместимым со всем вплоть до оригинальной функции glBegin(). Это ограничение будет действовать на протяжении всего потенциального будущего OpenGL и станет пределом его эволюции, делая альтернативы вроде Metal API все более предпочитаемыми…

Оригинал статьи:
http://renderingpipeline.com/2014/06/whats-the-big-deal-with-apples-metal-api/

Обзор

Metal — Apple Developer

Смотреть сессии о металле с WWDC22

Ускорение графики и многое другое.

Metal поддерживает аппаратное ускорение графики на платформах Apple, предоставляя API с низкими накладными расходами, богатый язык затенения, тесную интеграцию между графикой и вычислениями, а также беспрецедентный набор инструментов профилирования и отладки графического процессора. Metal 3 представляет мощные функции, которые помогают вашим играм и профессиональным приложениям использовать весь потенциал Apple Silicon. Теперь вы можете отображать графику высокого разрешения за меньшее время, быстрее загружать ресурсы, обучать сети машинного обучения с помощью графического процессора и т.  д.

Что нового в Metal 3

Повышение масштаба MetalFX

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

Быстрая загрузка ресурсов

Оптимальная передача данных активов в текстуры и буферы Metal непосредственно из хранилища с использованием асинхронного ввода-вывода.

Компиляция шейдеров в автономном режиме

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

Сетчатые шейдеры

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

Бэкенд Metal для PyTorch

Новый бэкэнд Metal в PyTorch версии 1.12 обеспечивает высокопроизводительное обучение с ускорением на GPU с использованием MPS Graph и примитивов Metal Performance Shaders.

Начать

Новые функции трассировки лучей

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

• Документация

  Просмотрите последнюю документацию, включая справочник по API и статьи.

  • Металл
  • Спецификация языка затенения металла
  • Таблицы набора характеристик металла (PDF)
  • Таблицы набора характеристик металла (числа)
  • МеталКит
  • Металлические шейдеры производительности

• Металл-CPP

  Добавление функциональности Metal в графические приложения, игры и игровые движки с использованием заголовков Metal C++ с низкими издержками.

  • Начало работы
  • Скачать пример кода
• Плагин Metal

  для TensorFlow

  TensorFlow-Metal PluggableDevice добавляет улучшения в обучение машинному обучению за счет новых операций, ускоренных на графическом процессоре, пользовательских операций и поддержки распределенного обучения.

  • Начало работы

• Инструменты для разработки металла для Windows

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

  • Скачать сейчас

Начало работы с Metal-cpp — Metal

Metal-cpp — это интерфейс C++ с низкими издержками для Metal, который помогает добавлять функциональные возможности Metal в графические приложения, игры и игровые движки, написанные на C++.

Highlights

• Вставьте альтернативный интерфейс C++ в заголовки Metal Objective-C.
• Прямое сопоставление всех классов, констант и перечислений Metal Objective-C с C++ в пространстве имен MTL C++.
• Отсутствие измеримых накладных расходов по сравнению с вызовом заголовков Metal Objective-C из-за встраивания вызовов функций C++.
• Контейнеры-оболочки, требующие дополнительных выделений, не используются.
• Идентичные файлы заголовков и доступность функций/констант/перечислений для iOS, iPadOS, macOS и tvOS.
• Обратная совместимость: все функции bool MTL::Device::supports...() проверяют, существуют ли требуемые селекторы, и автоматически возвращают false , если нет.
• String (ErrorDomain) константы имеют слабую связь и автоматически устанавливаются на nullptr , если они недоступны.

Инструкции по установке

1. Подготовьте свой Mac.

2. Добавьте папку metal-cpp в путь поиска заголовков вашей системы сборки.

В Xcode:

• Щелкните навигатор проектов.
• Щелкните Проект.
• Щелкните Параметры сборки.
• Поиск путей поиска заголовков.
• Добавьте путь к извлеченной папке, metal-cpp/ .
• Найдите диалект языка C++ и убедитесь, что для него установлено значение C++17 или более поздней версии.
• Обязательно добавьте фреймворки Foundation, QuartzCore и Metal в список фреймворков, которые нужно связать на вкладке «Фазы сборки».

3. Создайте реализацию.

metal-cpp — это библиотека только для заголовков. Чтобы сгенерировать реализацию, добавьте следующий код в один из ваших файлов .cpp:

 #define NS_PRIVATE_IMPLEMENTATION
#define CA_PRIVATE_IMPLEMENTATION
#define MTL_PRIVATE_IMPLEMENTATION
#include <Фонд/Foundation.hpp>
#include <Металл/Металл.hpp>
#include  

Примечание. Заголовки metal-cpp также можно заключать в кавычки.

4. Используйте metal-cpp.

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

 #include  hpp>
#include <Металл/Металл.hpp>
#include  

Важно: Не определяйте макросы NS, MTL или CA _PRIVATE_IMPLEMENTATION более одного раза.

Альтернативный вариант одиночного заголовка Metal-cpp

Для удобства вы также можете использовать metal-cpp как одиночный заголовок, включенный в ваш проект.

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

 ./SingleHeader/MakeSingleHeader.py Foundation/Foundation.hpp QuartzCore/QuartzCore.hpp Metal/Metal.hpp 

После завершения команда создаст один файл: ./SingleHeader/Metal.hpp . Этот файл включает в себя все, что вам нужно для использования metal-cpp в вашем проекте.

Не забудьте сгенерировать реализацию в одном файле CPP.

 #define NS_PRIVATE_IMPLEMENTATION
#define CA_PRIVATE_IMPLEMENTATION
#define MTL_PRIVATE_IMPLEMENTATION
#include  

Вопросы управления памятью

Metal-cpp следует политикам выделения объектов Cocoa и Cocoa Touch.