Как стать автором
Обновить

Комментарии 24

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

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

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

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

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


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

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

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

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

А есть вывод glxinfo или какого-нибудь аналога?
Я пока не встречал аналога 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
Ну не то, чтобы мне прямо нужно, просто от статьи «OpenGL на Apple M1» я ожидал большего.
glxinfo проверенная штука, всё покажет, а так вон видно sView умеет только 2.1. Возможно CAD Assistant умеет только 4.1, а фактически можно открыть 4.6 контекст.
Статья подтверждает, что OpenGL стек еще есть и не изменился на M1 по сравнению с x86 + Intel Iris и прочими видеокартами на OS X. И это отлично, потому что миграция на чистый Metal не всегда приемлема, а Angle пока с ним работает недостаточно хорошо. Конечно, возможны забавные особенности вроде более быстрого glBufferData, чем glMapBuffer, но все-равно совместимость с 4.1 не поломали и можно выдохнуть спокойно, а не ждать гневных багрепортов.
Именно! Больше всего я опасался, что Apple под соусом новой «лучшей» платформы возьмёт и вырежет OpenGL или зарежет его функциональность.
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).

Стоило бы остановиться на осмотре 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 еще тянут кота за все подробности)

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

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

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

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

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

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

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

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

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории