Немного про 3д форматы файлов

есть несколько довольно популярных форматов, каждый со своими нюансами

1. OBJ - простые, текстовые, легко читаются, легко парсятся. Есть дополнительные файлы материалов MTL, которые описывают простые свойства вроде текстурок. Из проблем - не поддерживают кучу нужных в современном 3д свойств, вроде анимаций, сцен, света, иерархий объектов и тд. Много весят из-за текстового формата. В целом это простой как палка, но очень ограниченный способ передать геометрию и простые свойства одного конкретного объекта

2. STL - в прошлом очень популярный формат для 3д печати, все еще часто встречается. Из плюсов - простой, поддерживается тоже почти везде. Из минусов - содержит только геометрию, много весит, не содержит информацию о единицах измерения. В целом информации в нем даже меньше, чем в OBJ, где хотя бы uv и нормали есть. По сути подходит только для передачи геометрии

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

4. glTF и GLB - создан специально для передачи и загрузки 3д сцен в приложения вроде игр и веб-сайтов. Открытый, современный стандарт, поддерживающий и сцены, и все возможные свойства вроде анимаций, камер, освещения, трансформаций и прочего. Очень хорошо сжимается, как раз glTF - текстовый вариант с данными в виде отдельных файлов, а GLB - бинарный формат, где все данные уже встроены внутри. Множество языков, движков и библиотек используют его как де-факто формат передачи сцен и моделей. Тем не менее, благодаря своей оптимизации для конечного использования, меньше подходит для передачи между 3д редакторами в процессе арт пайплайна (т.е. лучше использовать как финальный экспортный формат, а не в процессе работы). Создан Khronos Group, которые отвечают за OpenGL и Vulkan

5. USD и USDZ - новый формат сцен от Pixar. По аналогии с glTF и GLB, USD - несжатая версия, а USDZ - запакованная в один файл. Обладает мощными средствами композиции сцен, предназначен для работы с огромными сценами. Становится стандартом в мире 3д редакторов и VFX, то есть используется крупными студиями. Больше подходит именно для процесса работы над 3д сценами в различных редакторах, чем для конечных программ, которые эти сцены будут уже использовать. Из минусов - сжимает данные хуже glTF, содержит множество ненужных для конечного применения данных, в целом ужасно переусложнен для этой задачи. Полноценная поддержка есть только в официальной реализации для C++ и Python, в других языках в лучшем случае малая часть спецификации реализована. Даже Apple поддерживают отнюдь не полный функционал USD. По словам контрибьютора Three.js, парсер USD весит больше, чем вся их графическая библиотека, и его написание и поддержание требует намного больше усилий, чем оправдано. Учитывая, что USD для конечного использования все равно подходит хуже glTF, многие преобразуют glTF в USD вместо создания его с нуля даже там, где он нужен

6. 3MF - специально созданный формат для 3д печати. В отличие от STL, поддерживает и несколько объектов в сцене, и материалы, и встраивание параметров печати в сам файл, как и единицы измерения. За пределами 3д печати почти не используется

7. STEP - стандарт ISO для обмена 3д моделями между CAD программами. В отличие от других форматов, представляет модели не как меши, то есть набор полигонов, а с помощью NURBS, то есть математических формул. Если проводить аналогию с 2д графикой, то другие форматы растровые, а этот - векторный. Он позволяет сохранить абсолютную точность модели в любом масштабе, благодаря чему используется и в CAD системах, и при отправке на производство. Последнее время стал использоваться в сфере 3д печати для передачи точных моделей в слайсеры

8. IGES - устаревший предшественник STEP для CAD программ. Менее надежен, но еще встречается

Итого, получаем следующий список оптимальных форматов под задачу:

1. 3д печать - 3MF
2. Простая геометрия - OBJ
3. Работа с арт конвейером, обмен между 3д и видео редакторами - USD
4. Игры, веб, AR/VR, другие приложения, которые рендерят сцены в реальном времени - glTF
5. CAD-программы - STEP

Судя по всему, Телеграм не даст мне уместить всю необходимую информацию в одно сообщение (обзор 3д форматов выше буквально в паре символов от лимита).

Придется разбивать на несколько самостоятельно, чтобы избежать обрывков информации в отдельных сообщениях

Начну серию постов про графические API, как вижу их я. Постараюсь про каждое расписать с плюсами и минусами, когда и зачем его стоит или не стоит брать

Сперва, наверно, классический дедушка - OpenGL. Появился еще в 80-х, когда видеокарты были намного слабее процессоров, что сказалось на его дизайне. Сильно изменился в 2010 году с выходом версии 3.3, была сделана попытка хоть как-то адаптировать его под современные реалии. Старый дизайн стал называться Compatibility Profile, а новый - Core Profile

По сути, весь OpenGL построен на идее глобального неявного контекста, от состояния которого зависит, что и как сейчас произойдет при исполнении команд на видеокарте. В Compatibility Profile на этом основано вообще всё, тогда как в Core Profile сделали несколько более явных сущностей, чтобы минимизировать использование этого глобального контекста

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

В целом, OpenGL уже просто морально устарел: последняя версия вышла в 2017 году, новых версий не будет, а на всех платформах вообще поддерживается максимум версия 4.1, выпущенная в 2010. Всё дальнейшее развитие мира графики идет в API нового поколения, заменивших его

Другой проблемой этого API является перекладывание большей части работы на драйвер, благодаря чему резко повышался риск багов в нем и расхождений со спецификацией. Например, автор проекта glium пытался сделать безопасную OpenGL обертку на языке Rust, но потерпел неудачу и забросил проект, указав причиной именно неадекватное количество багов драйверов и противоречащего спецификации поведения. Настолько, что безопасно и надежно обработать все эти случаи просто оказалось невозможным

Кроме того, при использовании OpenGL происходит много ситуаций, когда процессор просто блокируется в ожидании видеокарты, что негативно сказывается на общей производительности. Особенно сильно этому подвержен Compatibility Profile. С одной стороны, это упрощает API, но с другой - замедляет работу программы по сравнению с более современными аналогами, где такой проблемы нет

Тем не менее, несмотря на такое обилие минусов, OpenGL все равно пользуется популярностью у инди-разработчиков. Тому есть несколько причин:

1. Огромное обилие информации, накопленное за десятки лет использования

2. Поддержка действительно старого компьютерного железа. Старше 20 лет. Тогда как новые API поддерживают только видеокарты, произведенные в 2010-2012 годах и новее

3. Относительная простота использования. Несмотря на то, что весь дизайн OpenGL побуждает делать ошибки, в целом он требует написания довольно малого количества относительно простого кода. Грубо говоря, если вывод треугольника на экран на OpenGL может занять 150 строк кода, то аналог на его замене, Vulkan, будет уже ближе к 800 строкам. А это довольно важно для инди разработчиков, у которых нет огромных ресурсов ААА студий

4. Какая-никакая, но поддержка на всех платформах, в отличие от более современных вариантов

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

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

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

дальше переходим к современным API, которые были созданы примерно в 2010-е годы на замену OpenGL, и развиваются по сей день

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

Это API было создано Khronos Group как замена OpenGL на базе наработок AMD по Mantle, и призвано решить проблемы предшественника, сделав всё гораздо более явным и дав новые возможности для оптимизации. К сожалению, по моему мнению, они с этими идеями сильно перестарались

На Vulkan в порядке вещей, когда аналог hello world занимает больше тысячи строк. Просто потому что авторы решили сделать ВСË явным и требующим отдельного кода. Частично это было сделано для облегчения драйверов, чтобы они были стабильнее (не слишком помогло, те же встроенные видеокарты Intel по-прежнему работают через раз). С другой стороны, это должно было облегчить написание многопоточного кода и уменьшить количество ошибок. Но в итоге получается просто когнитивный перегруз, когда простейшие действия требуют сотен и тысяч строк кода.

Это в чем-то похоже на попытку писать реальные приложения на ассемблере - потенциально возможно очень хорошо оптимизировать, но в то же время получается еще больше пространства для ошибок + чаще всего результат окажется хуже, чем у автоматически сгенерированного асма из более высокоуровневых языков

Так и Vulkan - потенциально он позволяет добиться х2 и более прироста производительности относительно OpenGL, и есть достаточно примеров подобных случаев. Но в то же время, достаточно примеров и обратного - когда сложность Vulkan мешала адекватно оптимизировать код на нем, и результат работал даже медленнее, чем старый OpenGL. К тому же, трудозатраты просто несоизмеримы

По этой же причине большинство знакомых мне людей, работающие с Vulkan, первым делом пишут свои обертки над ним, чтобы как-то спрятать это расчудесное API подальше от реального кода, который они пишут. Просто потому что иначе писать невозможно, слишком много трудозатрат для базовых вещей. Но т.к. каждый делает это отдельно и для себя, всё это превращается в бесконечное велосипедостроение

К слову, в отличие от старых API, Vulkan нативно доступен далеко не на всех платформах. Он в принципе не поддерживает браузерную среду, а также платформы компании Apple. В случае последних существует слой совместимости MoltenVK, реализующий поддержку Vulkan поверх другого современного API, Metal. Но он отстает по возможностям от обоих и имеет много проблем со стабильностью

Из плюсов же Vulkan активно поддерживается и обладает огромным количеством возможностей, которые недоступны OpenGL ни в каком виде. И в правильных руках позволяет действительно выжать из видеокарты максимум. Также это самое кроссплатформерное из всех новых графических API, работающее нативно на Windows, Linux, Android и Nintendo Switch, а через MoltenVK и на macOS и iOS. А также единственное открытое API из современных нативных.

Кроме того, Vulkan имеет слои валидации, которые могут проверять корректность работы с API, находясь между драйвером и вашим кодом. Однако это далеко не панацея, и многие вещи они пропускают

Для отладки можно использовать RenderDoc, как и с OpenGL. Он довольно популярен и многое умеет, но т.к. сделан коммьюнити, а не авторами Vulkan, то частенько отстает от изменений самого API

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

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

далее идет DX12, он же DirectX 12, он же D3D12, он же Direct3D 12.

Актуальное графическое API от компании Microsoft для платформ Windows и Xbox. Через сторонние слои совместимости возможен запуск большинства приложений на Linux, но официально он не поддерживается

Несмотря на название, имеет больше общего с Vulkan, чем с предшественником, DX11. Тоже довольно низкуровневое API, тоже имеет аналог слоев валидации, тоже перекладывает многое на разработчика

Однако в целом попроще и более продумано, чем Vulkan. Меньше шероховатостей в API при использовании, большее удобство и стабильность, больше гарантий для разработчика. А также является первым в очереди на адаптацию новых фич в мире графики - пока Vulkan только несколько лет планирует реализацию, в DX12 она уже давно доступна.

Кроме того, имеет Agility SDK от Microsoft, который позволяет использовать более новые фичи DX12 в своем приложении относительно тех, что доступны в системе пользователя

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

Последние годы активно набирает популярность, в первую очередь переманивая разработчиков с Vulkan и старых версий DirectX

Из минусов можно назвать все же значительную переусложненность относительно OpenGL, официальную поддержку только платформ Microsoft, а также отсутствие поддержки версий Windows до 10

И пусть на Linux проекты vkd3d и dxvk, а также Proton позволяют запускать многие игры и приложения на DX12, все равно достаточно тех, с которыми имеются проблемы. А также огорчает абсолютное отсутствие поддержки мобильных устройств и платформ Apple

Последнее время DX12 идет на сближение с Vulkan, начиная поддерживать его формат шейдеров и позволяя собирать свои шейдеры под него

Можно сказать, что DX12 - это Vulkan, но сделанный по-человечески, однако лишь для пользователей Windows и Xbox. Так как это основные платформы ПК гейминга, большинство крупных студий в первую очередь используют именно данное API, и рекомендуют его даже при наличии поддержки Vulkan как более стабильное. Однако для малых коллективов и инди разработчиков оно все же может быть слишком трудозатратным, равно как и не подходящим при желании поддержки множества платформ

И последним из современных нативных API является Metal от компании Apple

Это очень интересный пример - отличное, чуть ли не эталонное API и лучший инструментарий к нему, но доступное лишь на платформах одной компании. Благодаря чему крайне нишевое

В отличие от своих прямых конкурентов в лице Vulkan и DX12, Metal не только не усложнился относительно OpenGL, но даже значительно упростил написание кода, при этом уйдя от устаревшей парадигмы на современный дизайн без раздувания самого API

И при этом, при всех своих удобстве и простоте, Metal поддерживает 90% возможностей своих конкурентов, требуя ради них в несколько раз меньших объемов кода

Множество знакомых, плотно работавших с ним, считают его лучшим графическим API, и я склонен согласиться

Разработчик движка Unity, добавлявший поддержку всех трех современных API в него, вообще по итогу сказал, что считает Metal лучшим выбором для новичка, даже лучше OpenGL, несмотря на его закрытость

Собственно, Metal настолько доступен к пониманию, что на нем коллеги на одном из прошлых мест работы делали виджет 3д навигатора в мобильном приложении на iOS. Обычные мобильные разработчики, пишущие на Swift, вообще без какого-то значительного низкоуровневого кода, который просто необходим на других API

вдобавок к такому API идут инструменты отладки Xcode. Да, сам по себе Xcode отвратителен как IDE для написания кода, но именно инструменты отладки Metal там эталонные. Там больше удобства и возможностей, чем и в RenderDoc от коммьюнити, и в PIX от Microsoft. И он позволяет отлаживать произвольные программы, в том числе собранные вне Xcode. К тому же синхронные обновления с самим Metal

Собственно, даже люди, пользующиеся обертками над нативными графическими API, нередко предпочитают использовать именно инструменты Metal для отладки, даже при наличии поддержки в PIX и RenderDoc

Но все эти чудесные плюсы перечеркиваются одним жирным минусом - Metal работает только на платформах Apple, и больше нигде. Если у вас есть устройство на macOS - вы очень счастливый человек, потому что можете использовать именно его. Но если вас интересует разработка под другие операционные системы, то из уютного Metal придется выйти в мир жестокой реальности Vulkan и DX12, где надо в 5 раз больше кода, чтобы сделать то же самое

А учитывая, что львиную долю десктопных операционных систем составляет Windows - выйти за пределы macOS и Metal всё же придется. Кто-то решает это изначальным использованием Vulkan на всех платформах, кто-то делает отдельные рендер бэкенды на DX12 и Metal, чтобы наоборот, не связываться с Vulkan. Но такова жестокая реальность - пользоваться только одним удобным нативным API скорее всего не получится

Особняком стоят графические API в виде библиотек - оберток

Это API, реализуемые не драйвером в системе напрямую, а поверх вышеперечисленных нативных API в виде некой обертки с собственным интерфейсом

Их довольно много, для разных задач и поверх разных API. Как пример можно привести IGL от Meta и SDL GPU

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

Я считаю, что есть выбор получше, о котором и расскажу дальше

Можно было заметить, что на всех платформах OpenGL придумали ту или иную замену. На всех, кроме браузеров, где доисторический WebGL до сих пор являлся единственным доступным вариантом

Собственно, это и было призвано исправить появление WebGPU в 2021 году. Рабочая группа W3C из Google, Mozilla, Apple и Khronos опубликовали первый черновик нового стандарта графического API для браузеров

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

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

Так появились dawn, реализация на C/C++ под нужды Chromium, и wgpu - реализация на Rust под нужды Mozilla с привязками к другим языкам.

Rust версия не только весит почти в 10 раз меньше в виде библиотеки, но и давно вышла за пределы стандарта WebGPU, предлагая разработчикам возможности нативных API вне браузеров, вроде трассировки лучей и пуш констант

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

Таким образом, wgpu стала де-факто решением для графики в экосистеме Rust. Его используют и онлайн-игры, и игровые движки, и системы рендера, и рантаймы нейросетей, и GUI-библиотеки, и многие другие

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

wgpu позволяет использовать условные 80% возможностей современных нативных API, оставаясь при этом полностью кроссплатформерным и сохраняя сложность на уровне OpenGL. Что делает его идеальным выбором для большинства проектов, что и заметно по экосистеме и его использованию

Вдобавок, это реализация W3C стандарта, использующаяся в одном из главных браузеров, что говорит о поддержке и переносимости решений. Например, сейчас довольно легко перенести примеры для браузерного WebGPU с JS на Rust или C++ почти 1 к 1, именно благодаря данным фактам

К тому же, это единственное современное API, поддерживающее одновременно как все нативные платформы, так и браузеры. А такая широкая поддержка платформ позволяет отлаживать его любым инструментом для нативных API - и RenderDoc, и PIX, и Xcode

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

Собственно, это и есть то API, которым пользуюсь я везде, где мне в принципе нужна графика. OpenGL слишком отсталый, Vulkan и DX12 слишком трудозатратные для 99% задач, а Metal недоступен на большинстве платформ. В таких условиях WebGPU, а конкретно его реализация wgpu, является самым удобным и оптимальным решением, даже на нативных платформах

Отдельно стоит пройтись по шейдерам, которые нужны для любого графического API

шейдеры - это фактически специализированные программы для видеокарты на специализированном языке, зависящем от используемого API

Есть несколько вариантов языков для их написания:

1. GLSL - похож на C, используется в OpenGL и Vulkan

2. HLSL - похож на C++ относительно новых стандартов (около 14), используется в DX12, с недавних пор есть поддержка Vulkan

3. MSL - тоже похож на C++ (примерно 11 стандарт), используется исключительно в Metal

4. WGSL - похож на Rust, используется в WebGPU и библиотеках-реализациях

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

- Vulkan потребляет SPIR-V, полученный из GLSL или HLSL после сборки (забавный факт - изначально SPIR-V рассматривался как формат шейдеров для WebGPU, но из-за его непродуманности и нестабильности был отвергнут)

- DX12 потребляет DXBC, DXIL или (с недавних пор) SPIR-V, полученные из HLSL. DXBC - старый, менее оптимизированный, но более простой в получении формат, тогда как DXIL - более современный, более производительный, но более сложный. SPIR-V же изначально является форматом Vulkan, недавно он был добавлен в рамках расширения совместимости

- Metal потребляет AIR файлы, полученные после сборки из MSL

- WebGPU принимает WGSL файлы, после чего с помощью компилятора шейдеров превращает его в один из перечисленных выше форматов байткода для использования в нижележащем нативном API. У dawn компилятором служит tint, у wgpu - naga. При этом Naga отличается очень высокой производительностью, преобразуя один шейдер за примерно 150 микросекунд

На этапе преобразования из кода в байткод происходит валидация и оптимизация шейдеров (кроме SPIR-V, где недостатки формата не могут их гарантировать), и это может быть сделано заранее, например при сборке проекта.

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

Здесь снова виден возраст OpenGL, который не имеет возможности заранее оптимизировать или провалидировать код шейдеров, и драйвер должен делать это самостоятельно во время работы программы. И хотя в версии 4.6 добавили опциональную поддержку SPIR-V, данная версия доступна исключительно на Windows и Linux, и фичу используют крайне редко

Тем временем, Apple анонсировали выпуск полной поддержки WebGPU в Safari 26, которая уже в бете

Все Chromium-based браузеры (то есть всё, что не Сафари или Огнелис) уже давно поддерживают на Windows и macOS

Это значит, что ждем только Firefox (работает только в Nightly и не везде) и Chromium на Linux для полной поддержки везде

Новость на самом деле очень важная, потому что Apple тянули с поддержкой WebGL 2 много лет. При этом их браузер второй в мире по популярности после Chrome, то есть они могут легко затормозить развитие технологии, просто не поддерживая ее.

Но тут видимо даже им уже надоел WebGL, раз они так оперативно катят поддержку

Большая поддержка означает большее использование и большие шансы на окончательное принятие стандарта (сейчас он в статусе кандидата, ждут именно использование в браузерах)

А это означает и лучшее развитие упомянутых библиотек-реализаций для этих браузеров, которые можно (и нужно) использовать вне веба для написания графики под десктопы и мобилки

https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/

Как же так получилось, кто бы знал...

А мне вот адепты крестов говорили, что никому он не нужен и никто не использует (отдельный мем)

Сорри, но тут я не удержался уж, слишком сочно

Итак, Apple выложили информацию про новый Metal 4, который придет этой осенью с обновлением их операционных систем

Этим релизом они решили почти полностью сломать совместимость с нынешним Metal 3 и прошлыми версиями, ради большей совместимости с концепциями Vulkan и DX12

Теперь из старого API по сути остался только MTLDevice, все остальное изменено. Например, вместо MTLCommandQueue, теперь MTL4CommandQueue

Сделали аллокаторы, таблицы аргументов и прочие сущности, которые раньше только в более сложных API встречались

Главное изменение - теперь все ресурсы требуют ручной синхронизации, никакого автоматического отслеживания, которое было в Metal 3, OpenGL и WebGPU, и спасало от кучи ошибок

Из плюсов - добавили свой аналог DLSS 4, с генерацией кадров, денойзером, апскейлером и тд

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

В итоге, API сделали более дружелюбным к многопотоку и гораздо более похожим на Vulkan и DX12, но ценой кардинального усложнения и несовместимости со старым кодом

Причем Metal 3 уже поддерживал ручное управление ресурсами и прочие оптимизации, но они не были обязательными и не мешали просто использовать API для своих проектов без лишней сложности. А теперь оно становится и более трудным, и обязательным

Понятно, зачем Apple это сделали - они уже давно очень хотят на игровой рынок, и это упростит миграцию игр от крупных студий с Windows, которые и так используют DX12 или, реже, Vulkan

Но для обычных разработчиков, особенно и так пишущих под платформы Apple на Metal, это огромное усложнение и раздувание кода, как мне кажется, будет скорее жирным минусом

С такими новостями WebGPU остается единственным выбором на нативе для одиночек и малых коллективов, когда теперь уже все три нативных API стали слишком переусложнены

По сути, сейчас из простых, но мощных вариантов - только wgpu, dawn, sdl-gpu и blade.

Но у wgpu преимущество, благодаря широкой распространенности и популяризации стандарта, на котором оно основано

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