Розенцвейг – первый драйвер графического процессора, соответствующий M1.

Соответствующие драйверы OpenGL® ES 3.1 теперь доступны для графических процессоров семейств M1 и M2. Это означает, что драйверы совместимы с любым приложением OpenGL ES 3.1. Заинтересованы? Просто установите Linux!

Для существующих Асахи Линукс пользователи, обновите свою систему с помощью dnf
upgrade (Федора) или pacman
-Syu (Арка) для последних драйверов.

Наша реконструированная, бесплатная и графические драйверы с открытым исходным кодом являются мировыми только совместимая реализация OpenGL ES 3.1 для графического оборудования семейств M1 и M2. Это означает, что наш драйвер прошел десятки тысяч тестов, чтобы продемонстрировать свою правильность, и теперь признан в отрасли.

Чтобы стать соответствующей, «реализация» должна пройти официальный набор тестов на соответствие, предназначенный для проверки каждой функции спецификации. Результаты испытаний передаются в орган по стандартизации Khronos. После 30-дневный период рассмотрения, если проблем не обнаружено, реализация становится соответствующей. На веб-сайте Khronos перечислены все соответствующие реализации, включая наши драйверы для М1,
M1 Про/Макс/Ультра, М2и М2 Про/Макс.

Сегодняшняя веха касается не только OpenGL ES. Мы выпускаем первую совместимую реализацию любой графический стандарт для M1. И мы не планируем на этом останавливаться 😉

В отличие от наших, драйверы M1 производителя, к сожалению, не соответствуют любой стандартный графический API, будь то Vulkan, OpenGL или OpenGL ES. Это означает, что нет никакой гарантии, что приложения, использующие эти стандарты, будут работать на вашем M1/M2 (если вы не используете Linux). Это не просто теоретический вопрос. Рассмотрим Вулкан. Сторонняя сторона МолтенВК накладывает подмножество Vulkan поверх проприетарных драйверов. Однако этим драйверам не хватает ключевых функций, что нарушает работоспособность приложений Vulkan. Это мешает как разработчикам, так и пользователям, если они еще не перевели свои компьютеры M1/M2 на Linux.

Почему мы добиваться соответствия стандартам, когда производитель этого не сделал? Прежде всего, наша приверженность качеству. Мы хотим, чтобы наши пользователи знали, что они могут положиться на наши драйверы Linux. Мы хотим, чтобы стандартное программное обеспечение работало без хаков или портирования, специфичных для M1. Мы хотим подать правильный пример экосистеме: путь вперед — это внедрение открытых стандартов, соответствующих спецификациям, без компромиссов в отношении «переносимости». Нас не устраивают проприетарные драйверы, проприетарные API и отказ от внедрения стандартов. Остальная часть отрасли знает, что прогресс достигается за счет сотрудничества между поставщиками. Мы тоже это знаем. Достижение соответствия — это победа для нашего сообщества, открытого исходного кода и открытой графики.

Конечно, Асахи Лина и я — два человека с минимальным финансированием. Немного неловко, что мы победили большую корпорацию…

Хотя еще не поздно. Они должны последовать нашему примеру!

OpenGL ES 3.1 обновляет экспериментальную OpenGL ES 3.0 и OpenGL 3.1 мы отправили в июне. Примечательно, что в ES 3.1 добавлены вычислительные шейдеры, обычно используемые для ускорения общих вычислений в графических приложениях. Например, 3D-игра может запускать физическое моделирование в вычислительном шейдере. Результаты моделирования затем можно использовать для рендеринга, устраняя задержки, которые в противном случае потребовались бы для синхронизации графического процессора с физическим моделированием процессора. Это позволяет игре работать быстрее.

Давайте остановимся на одной новой функции: атомарности изображений. Более старые версии OpenGL ES позволяли приложению считывать изображение, чтобы отобразить его на экране. ES 3.1 позволяет приложению писать к изображению, обычно из вычислительного шейдера. Эта новая функция обеспечивает гибкие алгоритмы обработки изображений, которые ранее необходимо было вписать в 3D-конвейер с фиксированными функциями. Однако графические процессоры массово параллельны, одновременно выполняя тысячи потоков. Если два потока пишут в одно и то же место, возникает конфликт: в зависимости от того, какой поток запускается первым, результат будет разным. У нас есть состояние гонки.

«Атомный» доступ к памяти обеспечивает решение условий гонки. Благодаря атомарности специальное оборудование в подсистеме памяти гарантирует согласованные, четко определенные результаты для операций выбора, независимо от порядка потоков. Современное графическое оборудование поддерживает различные атомарные операции, такие как сложение, которые служат строительными блоками для сложных параллельных алгоритмов.

Можем ли мы объединить эти две функции для атомарной записи изображения?

Да. Вездесущий OpenGL ES расширение, необходимый для ES 3.2, добавляет атомы, работающие с пикселями изображения. Например, вычислительный шейдер может атомарно увеличивать значение пикселя (10, 20).

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

Идея проста: чтобы выполнить атомарную операцию над пикселем, мы вместо этого вычисляем адрес пикселя в памяти и выполняем обычную атомарную операцию по этому адресу. Поскольку аппаратное обеспечение поддерживает обычную атомику, наша задача — «просто» вычислить адрес пикселя.

Если бы изображение располагалось в памяти линейно, это было бы просто: умножить координату Y на количество байтов в строке («шаг»), умножить координату X на количество байтов на пиксель и сложить. Это дает смещение пикселя в байтах относительно первого пикселя изображения. Чтобы получить окончательный адрес, мы добавляем это смещение к адресу первого пикселя.

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

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

Существует известный Алгоритм «битового вращения» для чередования битов. Вместо того, чтобы перемешивать один бит за раз, алгоритм перемешивает группы битов, распараллеливая задачу. Реализация этого алгоритма в коде шейдера повышает производительность.

На практике чередуются только младшие 7 бит (или меньше) каждой координаты. Это позволяет нам использовать 32-битные инструкции для «векторизации» чередования, помещая координаты X и Y в младшие и старшие 16 бит 32-битного регистра. Эти 32-битные инструкции позволяют нам одновременно чередовать X и Y, сокращая вдвое количество инструкций. Кроме того, мы можем использовать комбинированную инструкцию сдвига и сложения графического процессора. Собрав все воедино, мы чередуем 10 инструкций сборки графического процессора M1:

# Inputs x, y in r0l, r0h.
# Output in r1.

add r2, #0, r0, lsl 4
or  r1, r0, r2
and r1, r1, #0xf0f0f0f
add r2, #0, r1, lsl 2
or  r1, r1, r2
and r1, r1, #0x33333333
add r2, #0, r1, lsl 1
or  r1, r1, r2
and r1, r1, #0x55555555
add r1, r1l, r1h, lsl 1

Мы могли бы остановиться здесь, но что, если есть преданный
инструкция по чередованию битов? PowerVR имеет инструкцию «перемешать» shfl, а графический процессор M1 заимствован у PowerVR. Возможно, эта инструкция тоже была заимствована. К сожалению, даже если бы это было так, проприетарный компилятор не будет использовать его при компиляции наших тестовых шейдеров. Это затрудняет реверс-инжиниринг инструкции (если она существует) путем наблюдения за скомпилированными шейдерами.

Пришло время смахнуть пыль с мощной техники реверс-инжиниринга из волшебного детского сада: догадайся и проверь.

Дугал Джонсон
предоставил предположение. Рассматривая уже известные нам инструкции, он обратил особое внимание на инструкцию «обратного бита». Поскольку перестановка битов представляет собой разновидность перетасовки битов, команду чередования следует кодировать аналогичным образом. Команда реверса битов имеет двухбитовое поле, определяющее операцию, со значением 01. Связанные инструкции для подсчитать количество установленных битов и найти первый установленный бит иметь значения 10 и 11
соответственно. Сюда входят все известные инструкции «сложной манипуляции с битами».

Существует одно значение двухбитного перечисления, которое не наблюдается и неизвестно: 00. Если эта инструкция чередования существует, она, вероятно, закодирована как инвертирование битов, но с кодом операции.
00 вместо 01.

Есть сложность: три известные инструкции имеют один источник входных данных, а наша инструкция чередует два источника. Куда делся второй источник? Мы можем сделать предположение, основываясь на симметрии. Предположительно, чтобы упростить аппаратный декодер, инструкции графического процессора M1 обычно кодируют свои источники в одинаковых местах в инструкциях. В трех других инструкциях в арифметической инструкции с двумя источниками есть пробел там, где мы ожидаем, что будет второй источник. Вероятно, там находится второй источник.

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

Остаётся только написать шейдер которая проверяет, что загадочная инструкция возвращает чередующийся результат для каждого возможного ввода. Поскольку инструкция принимает два 16-битных источника, их около 4 миллиардов ($2^32$) входы. С нашим драйвером графический процессор M1 успевает проверить их все менее чем за секунду, и вердикт выносится: это наша инструкция чередования.

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

И это то, что имеет значение.

Спасибо тебе Хронос и
Программное обеспечение в общественных интересах
для поддержки открытых драйверов.

Вернуться домой