Metal developer tools for windows что это
Обновлено: 07.07.2024
Технологический митап, организованный международным IT-разработчиком Altenar в формате открытого и доверительного разговора про насущные проблемы в области разработки ПО, собрал немало участников из числа начинающих и продвинутых программистов.
Делимся содержанием наиболее интересных докладов.
Наиболее заметным стало выступление независимого WEB-разработчика Антона Грибанова. Он поделился своим опытом использования DevTools. На самом деле, обзорных статей по заявленной тематике для профессионалов немало. С ними легко можно ознакомиться на профильных ресурсах (тык, тык, тык, тык).
Данная статья, прежде всего, обращена к тем, кто еще находится в самом начале своего пути к программистскому Олимпу. Поэтому, если вы матерый разработчик, вас вряд ли заинтересует дальнейшее повествование. Хотя, вы можете поделиться своим богатым жизненным опытом в комментариях к публикации.
Инструменты разработчика (от англ. «development tools» или сокращённо «DevTools») ─ это программы, позволяющие создавать, тестировать и отлаживать (debug) программное обеспечение.
Современные браузеры, Safari, Firefox, Microsoft Edge, Chrome, Яндекс и другие, имеют встроенные инструменты разработчика, позволяющие просмотреть исходный код сайта. Отдельно устанавливать их не требуется. С их помощью можно просматривать и отлаживать HTML сайта, его CSS и Javascript. Также можно проверить сетевой трафик, потребляемый сайтом, его быстродействие и много других параметров.
В правом углу размещенной выше иллюстрации можно увидеть структуру web-страницы и стили, примененные к текущему элементу.
Типичная веб-страница представляет собой текстовый файл в формате HTML, который определяет структуру и контент страницы, а также может содержать ссылки на файлы в других форматах (текст, графические изображения, видео, аудио, базы данных и др.), а также гиперссылки для быстрого перехода на другие веб-страницы или доступа к ссылочным файлам.
Несколько веб-страниц, объединенных общей темой и дизайном, а также связанных между собой ссылками, образуют — веб-сайт. При этом образующие веб-сайт страницы могут находиться на одном или нескольких веб-серверах, которые могут располагаться в одном дата-центре или удаленно друг от друга, зачастую в разных странах.
HTML (англ. HyperText Markup Language) ─ это скелет веб-страницы. Для того, чтобы вся эта история начала двигаться и нужен Javascript (календарики, выпадающее меню, всплывающие окна, анимация и прочее, делается с помощью JS). Для придания странице божеского вида вам понадобится CSS (каскадные таблицы стилей).Представим HTML-документ в простейшей форме:
На 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 все более предпочитаемыми…
Металл является низким уровнем, с низким уровнем накладных расходов аппаратное ускорение 3D - графики и Compute Shader API , созданный Apple , . Он дебютировал в iOS 8 . Metal объединяет в одном API функции, аналогичные OpenGL и OpenCL . Он предназначен для повышения производительности, предлагая низкоуровневый доступ к оборудованию графического процессора для приложений на iOS , iPadOS , macOS и tvOS . Его можно сравнить с низкоуровневыми API на других платформах, таких как Vulkan и DirectX 12 .
Metal - это объектно-ориентированный API, который можно вызывать с помощью языков программирования Swift или Objective-C . Полноценное исполнение на графическом процессоре контролируется с помощью Metal Shading Language. Согласно рекламным материалам Apple: «MSL [Metal Shading Language] - это единый унифицированный язык, который обеспечивает более тесную интеграцию между графическими и вычислительными программами. Поскольку MSL основан на C ++, вы найдете его знакомым и простым в использовании».
СОДЕРЖАНИЕ
Функции
Metal стремится обеспечить доступ к графическому процессору с низкими издержками. Команды заранее кодируются, а затем отправляются в графический процессор для асинхронного выполнения. Приложение контролирует, когда ждать завершения выполнения, что позволяет разработчикам приложений увеличивать пропускную способность, кодируя другие команды, пока команды выполняются на графическом процессоре, или экономить энергию, явно ожидая завершения выполнения графическим процессором. Кроме того, кодирование команд не зависит от ЦП, поэтому приложения могут кодировать команды для каждого потока ЦП независимо. Наконец, состояния рендеринга предварительно вычисляются заранее, что позволяет драйверу графического процессора заранее знать, как настроить и оптимизировать конвейер рендеринга перед выполнением команды.
Metal улучшает возможности программирования GPGPU за счет использования вычислительных шейдеров . Metal использует специальный язык шейдинга на основе C ++ 14 , реализованный с помощью Clang и LLVM .
Metal предлагает разработчикам приложений гибкость при создании ресурсов Metal (буферов, текстур). Ресурсы могут быть выделены на центральном процессоре, графическом процессоре или на обоих, и предоставляют средства для обновления и синхронизации выделенных ресурсов. Metal также может обеспечивать соблюдение состояния ресурса в течение срока службы кодировщика команд.
В macOS Metal может предоставить разработчикам приложений право по своему усмотрению указывать, какой графический процессор следует выполнять. Разработчики приложений могут выбирать между маломощным встроенным графическим процессором центрального процессора, дискретным графическим процессором (на некоторых MacBook и Mac) или внешним графическим процессором, подключенным через Thunderbolt. Разработчики приложений также имеют предпочтение относительно того, как команды графического процессора выполняются на каких графических процессорах, и предлагают рекомендации, на каком графическом процессоре определенная команда наиболее эффективна для выполнения (команды для рендеринга сцены могут выполняться дискретным графическим процессором, а постобработка и отображение могут обрабатывается встроенным графическим процессором).
Шейдеры Metal Performance
Metal Performance Shaders - это высокооптимизированная библиотека графических функций, которая может помочь разработчикам приложений достичь высокой производительности при одновременном сокращении работы по поддержке функций, специфичных для семейства графических процессоров. Он предоставляет такие функции, как:
- Алгоритмы фильтрации изображений
- Обработка нейронной сети
- Расширенные математические операции
- трассировка лучей
История
Metal доступен со 2 июня 2014 года на устройствах iOS под управлением Apple A7 или новее, а с 8 июня 2015 года - на компьютерах Mac (модели 2012 года или новее) под управлением OS X El Capitan .
5 июня 2017 года на WWDC Apple анонсировала вторую версию Metal, которая будет поддерживаться macOS High Sierra , iOS 11 и tvOS 11 . Metal 2 не является отдельным API от Metal и поддерживается тем же оборудованием. Metal 2 обеспечивает более эффективное профилирование и отладку в Xcode , ускоренное машинное обучение , снижение нагрузки на ЦП , поддержку виртуальной реальности в macOS и , в частности, особенности графического процессора Apple A11 .
На WWDC 2020 Apple объявила о переходе с Mac на микросхему Apple . Компьютеры Mac, использующие микросхему Apple, будут оснащены графическими процессорами Apple с набором функций, объединяющим то, что ранее было доступно в macOS и iOS, и смогут использовать преимущества функций, адаптированных к архитектуре отложенного рендеринга на основе плитки (TBDR) графических процессоров Apple.
Поддерживаемые графические процессоры
В iOS, tvOS и macOS Metal поддерживает разработанные Apple SoC от Apple A7 или новее. В macOS Metal также поддерживает Intel HD и Iris Graphics серии HD 4000 или новее, графические процессоры AMD GCN и AMD RDNA . Графические процессоры NVIDIA поддерживаются, но драйверы Metal для новых устройств (серии 10 и новее) недоступны, начиная с macOS Mojave.
Принятие
По данным Apple, более 148 000 приложений используют Metal напрямую, а 1,7 миллиона используют его через высокоуровневые фреймворки по состоянию на июнь 2017 года. Игры для macOS, использующие Metal для рендеринга , перечислены ниже.
Фреймворк относится к числу новейших разработок Apple, однако совместим с целым спектром чипов Intel, NVIDIA и AMD прошлых лет. Общий официальный ограничитель – сборка компьютера Mac должна быть не древнее 2012-го года, но все варьируется от модели к модели.
В силу того, что модельный ряд Mac включает в себя десктопы, моноблоки и ноутбуки разных конфигураций, единое требование, «не старше 2012-го года», следует воспринимать с оговоркой.
Список моделей, поддерживающих Metal, ниже:
- 21,5-дюймовые iMac от 2012 и новее.
- 27-дюймовые iMac от 2012 и новее.
- 27-дюймовые iMac с дисплеями 5K Retina образца 2013 и новее.
- Mac Mini 2012 года выпуска и новее.
- Mac Pro, выпущенные в середине 2012 и конце 2013 гг.
- Новейшие 12-дюймовые MacBook образца весны 2015.
- MacBook Air с дисплеями 11 и 13 дюймов 2012 и новее.
- 13-дюймовый и 15-дюймовый MacBook Pro 2012 и новее.
- MacBook Pro с Retina-дисплеем, обе модификации с диагональю 13 и 15 дюймов, новее 2012.
Как проверить дату выпуска своего Mac:
1. Нажмите на меню и откройте раздел Об этом Mac.
2. Под названием операционной системы и данными о ее версии находим строку с типом модели и периодом ее выпуска.
3. В данном примере – очевидно, что все преимущества Metal не будут доступны владельцу этого компьютера.
OS X El Capitan Developer Preview уже доступна для авторизованных тестеров, практически без проблем устанавливается и запускается на компьютерах, что помнят еще старый добрый Mavericks. Однако полноценная сборка OS X El Capitan в виде бесплатного обновления вряд ли окажется доступна раньше осени текущего года. К тому же Apple не спешит публиковать конкретные системные требования, так что пока придется отталкиваться от косвенных данных по совместимости с моделями прошлых лет. Зато яблочная компания своевременно позаботилась предложить разработчикам инструментарий MetalKit с настойчивой рекомендацией не мешкать в его освоении. Что и было сделано, по крайней мере, Epic Games еще год назад показала Unreal Engine 4, адаптированный для максимально полного использования возможностей Metal.
Читайте также: