OpenGL на Apple M1

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

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 24

    +1
    Один наивный вопрос, зачем ещё нужен OpenGL при сущестовании Vulkan? Помимо всяких консервативных CAD-систем с бородатым legacy, которые тянули OpenGL на дно все эти годы?
      +1

      Vulkan на Mac OS, в отличие от OpenGL, не поддерживается официально.
      OpenGL не сказать что очень уж желанный гость, но бородатое легаси худо-бедно позволяет ему работать (пока что).

        +4
        Ну во-первых, нативного Vulkan нет на платформе macOS (если говорить про виновника статьи).
        Во-вторых, Vulkan не является полноправной заменой OpenGL, как бы многим не хотелось закопать старый графический API.

        OpenGL гораздо проще для вхождения и не заставляет разработчика опускаться до специфичных для конкретного GPU особенностей. Может получиться более медленное приложение, но зато более кросс-вендорное. При этом преимущества по скорости могут быть и вовсе незаметными в конкретных случаях. То есть даже в случае написания нового приложения с нуля, выбор графического API пока остаётся неочевидным.
          0

          А что в Vulkan такого вендорно специфического? Вроде бы один стандарт на всех + вендорно-поддерживаемые расширения, как у OpenGL было и есть. Реально интересно.


          Про производительность из личного опыта — внезапно, Vulkan несколько проигрывает OpenGL на официальных линуксовых дровах Nvidia.

            0

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

              0

              А Vulkan просто падает, если не делать проверку?

            +2

            MoltenVK, кстати, вполне рабочий вариант (vulkan поверх Metal)

          0
          А есть вывод glxinfo или какого-нибудь аналога?
            0
            Я пока не встречал аналога glxinfo для macOS, поэтому на скорую руку могу дать вывод списка расширений OpenGL из DRAWEXE (если интересует что-то конкретное — могу выцепить):
            vglinfo -complete on Apple M1
            Draw[10]> vglinfo -complete
            OpenGL info:
            GLvendor: Apple
            GLdevice: Apple M1
            GLversion: 4.1 Metal - 70.12.7
            GLSLversion: 4.10
            Max texture size: 16384
            Max FBO dump size: 16384x16384
            Max combined texture units: 80
            Max MSAA samples: 4
            Viewport: 409x409
            GPU memory: 5461 MiB
            GPU Texture memory: 5461 MiB
            GLextensions: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_NV_texture_barrier
            ResolutionRatio: 1
              0
              Ну не то, чтобы мне прямо нужно, просто от статьи «OpenGL на Apple M1» я ожидал большего.
              glxinfo проверенная штука, всё покажет, а так вон видно sView умеет только 2.1. Возможно CAD Assistant умеет только 4.1, а фактически можно открыть 4.6 контекст.
                0
                Статья подтверждает, что OpenGL стек еще есть и не изменился на M1 по сравнению с x86 + Intel Iris и прочими видеокартами на OS X. И это отлично, потому что миграция на чистый Metal не всегда приемлема, а Angle пока с ним работает недостаточно хорошо. Конечно, возможны забавные особенности вроде более быстрого glBufferData, чем glMapBuffer, но все-равно совместимость с 4.1 не поломали и можно выдохнуть спокойно, а не ждать гневных багрепортов.
                  0
                  Именно! Больше всего я опасался, что Apple под соусом новой «лучшей» платформы возьмёт и вырежет OpenGL или зарежет его функциональность.
                  0
                  OpenGL стек на macOS ограничен сверху версией 4.1 независимо от приложения и железа. CAD Assistant инициализирует Core Profile (NSOpenGLProfileVersion3_2Core — выше значений в Cocoa не предусмотрено) и получает OpenGL 4.1, а sView Compatible Profile и получает OpenGL 2.1 (Apple решила не реализовывать Compatible Profile выше версий, хотя AMD/NVIDIA/Intel на Windows поддерживают совместимые профили тех же версий, что и Core Profile).
              0

              Стоило бы остановиться на осмотре OpenGL на М1 согласно заголовку.


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

              это неправда, Rosetta предлагает установку при первом распознанном Intel-based приложении.


              Тем интереснее понаблюдать за работой приложений через Rosetta 2:

              https://isapplesiliconready.com еще не попадался? Большинство приложений работают через Rosetta, самые проблемные связанны с виртуализацией (Parallels, Docker, VirtualBox; CodeWeavers кстати работает на ура) или с kernel extensions (kext полностью поменялся в Big Sur в принципе, и если Little Snitch, Microsoft с OneDrive быстро сориентировались и сделали релизы с поддержкой, то Google с Backup&Sync и File Stream еще тянут кота за все подробности)

                +1
                это неправда, Rosetta предлагает установку при первом распознанном Intel-based приложении.

                Я всего-лишь говорю о личном опыте: свежая система, установлены последние обновления, опробовано несколько приложений из архивов DMG (не через магазин — там-то Apple ясное дело должна была всё подготовить). Результат — приложения не запускались без каких-либо ошибок. Зачем мне кого-то обманывать?
                  –1

                  Глюк?
                  С моей стороны другой опыт — Intel-приложения работают в большинстве нормально. Даже с выходом 11.1, Google Backup&Sync заработал.
                  Кстати, большинство приложений из App Store также еще Intel-based. Можно посмотреть через About This Mac -> System Report -> Applications (сортировать по типу)

                  +1
                  самые проблемные связанны с виртуализацией

                  Ну казалось бы — git-gui, куда-уж проще приложение?
                  Ан нет — Intel-версия падает при запуске (хотя gitk запускается).

                  В первый раз пришлось собирать git из исходных текстов!
                    0

                    Раньше git ставил через их пакет, но потом понял, что через Homebrew гораздо удобней в плане обновлений (делает автоматически).
                    git-gui не пользуюсь, так что сказать не могу, но VS Code +git (via Homebrew) взлетели абсолютно нормально с первого раза. Да, поначалу git и другие пакеты собирались из исходников, но сейчас уже и бинарники для М1 в Homebrew начали появляться.

                  +1
                  И что защитит от удаления OpenGL в следующем минорном релизе? Apple уже поступала подобными образами.
                    0
                    Apple ведёт активную борьбу с открытыми стандартами и некоторое время назад объявила OpenGL «устаревшим»
                    в случае opengl «законодатели моды» — MS/sony с их проприетарными графическими апи в консолях. ПК-шные игры тоже почти всегда под DX пишут. С одной стороны, стукнуть бы конечно лбами ребят из amd/nvidia/intel/apple/microsoft/sony/google/nintendo и настойчиво попросить прийти к одному стандартному кроссплатформенному открытому графическому API. С другой возникает вопрос, кому это на самом деле нужно. OpenGL сейчас не предлагает кроссплатформенности, и потому постепенно отмирает.
                      0
                      Почему же не предлагает кроссплатформенности? Вот у нас в проекте как раз OGL, потому что он работает везде: Android (начиная с древних), Windows, Linux, Mac, iOS. Если перейти на Вулкан, отвалятся старые версии Андроид, и старые виндовые ПК, наверное, тоже.
                        0
                        на консолях то opengl нет, что уже само по себе не даст вам разработать игру под ПК и консоли одним API. А именно этой возможности хотелось бы от кроссплатформенного API — применимость для всех таргетов
                          0
                          и старые виндовые ПК, наверное, тоже.
                          vulkan sdk включает 32битные и 64битные библиотеки, так что поддержка старых ПК будет скорее зависеть от разработчиков использующих sdk. А на счёт android, поддержка устройств будет больше зависеть от Google.
                          0

                          Vulkan как-то так и появился.

                        Only users with full accounts can post comments. Log in, please.