Apple ведёт активную борьбу с открытыми стандартами и некоторое время назад объявила OpenGL "устаревшим" на своей платформе macOS Mojave 10.14, двигая разработчиков в сторону проприетарного графического API Metal. Анонсы Mac mini на чипсете Apple M1 (ARM) и macOS 11 Big Sur были восприняты с тревогой за судьбу OpenGL на этой платформе, однако различные источники успокаивали - OpenGL всё ещё поддерживается macOS Big Sur.

Оставался один вопрос - какую версию OpenGL может предложить графический процессор "новичка" Apple M1? Официальная документация Apple не обновлялась с 2017го года, и в ней, разумеется, нет упоминаний M1, а доступные на момент написания статьи не освещают данный момент.

Наконец, одним вопросом стало меньше! Как оказалось, macOS заявляет о поддержке OpenGL 4.1 для данного чипа, реализованного поверх Metal - то есть достигает верхней планки OpenGL, доступной на данной платформе для других GPUs, даже GeForce и Radeon.

Для сравнения - сверху скриншот CAD Assistant, запущенного на M1 (Mac mini '2020), а снизу на Intel UHD Graphics 630 (Mac mini '2018). Скриншот демонстрирует работу трассировки путей (Path Tracing) на GPU реализованного открытым графическим движком Open CASCADE Technology. Path Tracing требует OpenGL 4+ и представляется собой достаточно сложную GLSL программу - так что это неплохой способ проверить работоспособность GPU и реализации OpenGL.

К сведению, самая распространённые реализации OpenGL на Windows давно поддерживают версию OpenGL 4.5 ('2014) и выше, спецификации которой вышли без малого шесть лет назад, тогда как OpenGL 4.1 ('2010) уже исполнилось 10 лет! Но удивляться "отсталости" Apple тут нет смысла - компания нигде не объявляла войну OpenGL, но план вытеснения его с платформы macOS прослеживался уже давно, даже до представления общественности проприетарного графического API Metal в 2014ом году - сначала для iOS, а затем и для macOS. И, к сожалению, в отличие от других платформ, производители видеокарт не могут обновить версию OpenGL независимо от Apple.

Счётчик кадров в секунду в простой тестовой сцене со стеклянным шариком демонстрирует преимущество до двух раз M1 над Intel HD 630: 48 FPS против 25 FPS для маленького окошка и 14.8 FPS против 6.5 FPS для разрешения 1080p. Конечно, тут M1 выглядит достойно только по сравнению со слабым GPU процессора Intel i5 - цифры не идут ни в какое сравнение со 100+ FPS для 1080p на мобильных видеокартах среднего сегмента, таких как четырёхлетний GeForce 1060 GTX.

Для простоты эксперимента, CAD Assistant запускался через Rosetta - программное решение Apple для запуска x86-64 приложений на ARM64 процессоре (коим является новый M1). Важность такого инструмента трудно недооценить, ведь на момент анонса 99.9% программного обеспечения, доступного для macOS, рассчитано на процессоры Intel.

И тем удивительнее, как смело Apple играет своими мускулами, ведь Rosetta даже не предустановлена на macOS Big Sur! Приложения .app для Intel в Finder просто не запускаются на свежей системе, при этом система не показывает ни единого сообщения об ошибке. А вот запуск инсталлционного пакета .pkg сразу предложила установить Rosetta, после чего запуск старых приложений стал возможен.

Проблема совместимости со старыми приложениями при появлении новых платформ была актуальна не один раз. IA-64 (64битная архитектура процессоров Intel Itanium) не поддерживала запуск x86 приложений, а вот x86_64 (или AMD64, 64-битная архитектура современных процессоров Intel и AMD) была изначально рассчитана на совместимость с существующими x86 платформами и приложениями. Более того, 64-битная версия Windows XP для процессоров AMD вышла только в 2005 году - то есть спустя два года после выпуска первых процессоров AMD Athlon 64 / Opteron с этой архитектурой. Благодаря обратной совместимости (в том числе реализации WoW64 для прозрачного запуска 32битных приложений на 64битной Windows), 32битные x86 приложения и операционные системы оставались популярными ещё долгие годы.

Процессоры ARM физически не поддерживают инструкции x86 (как и наоборот), поэтому реализация запуска и эффективной работы приложений, написанных для другой архитектуры процессоров, представляет собой определённые сложности. Для Apple этот опыт был уже не первым в истории - первая версия Rosetta использовалась для запуска PowerPC приложений на процессорах Intel в 2006 году.

Подобные решения можно было наблюдать и на других платформах, таких как Android - когда аутсайдер мобильного рынка Intel пытался конкурировать с ARM. Такие версии Android на процессорах Intel позволяли запускать приложения собранные для архитектуры ARM. По моему опыту, работала такая комбинация не очень стабильно - многие приложения падали и работали некорректно. Тем интереснее понаблюдать за работой приложений через Rosetta 2:

  • Видеоплеер sView заработал без видимых проблем, но наблюдаются падения приложения при изменении размера окна.

  • CAD Assistant запускается и в целом работает, однако вскоре возникают артефакты отображения текста через рендер QtQuick.

  • Telegram запустился и вроде бы работает.

  • Edge также заработал на паре сайтов.

  • Firefox запустился, но работает некорректно (зависает открытие сайтов, падения).

Не могу сказать, связаны ли наблюдаемые проблемы именно с Rosetta, или с самой системой macOS Big Sur, или даже с графическими драйверами Apple M1. В будущем с появлением нативных ARM приложений для macOS этот вопрос может прояснится.

Intel версия sView на macOS Big Sur (ARM)
Intel версия sView на macOS Big Sur (ARM)
Битый текст в Intel версии CAD Assistant на macOS Big Sur (ARM)
Битый текст в Intel версии CAD Assistant на macOS Big Sur (ARM)

Английская версия публикации может быть найдена по следующей ссылке.

Обновление #1
Похоже артефакты текста в QtQuick (Qt5) связаны с проблемами реализации OpenGL на Apple M1 (судя по комментариям пользователей - проблема не воспроизводится на Intel). В Qt есть даже переменная, которая позволяет обойти проблему:

export QT_ENABLE_GLYPH_CACHE_WORKAROUND=1
open -a "/Applications/CAD Assistant.app"

Падения sView в момент масштабирования окна могут быть связаны с проблемами в обработке OpenGL из не-GUI потока (данная возможность была объявлена "устаревшей" в предыдущем обновлении macOS). Отключить отрисовку в отдельном потоке в sView можно специальным ключом:

/Applications/sView.app/Contents/MacOS/sView --cocoa-threaded=off