Я не против нового графического API, дружелюбного к разработчикам и способного выжать максимум производительности из современного графического процессора. Vulkan определённо переусложнён, а OpenGL тянет шлейф старых решений (в этом его и сила и слабость).
Но ведь WebGPU — это не новый графический API для всех, он разрабатывается с фокусом на браузеры (хотя по комментарию lain8dono у меня сложилось ощущение, что это не совсем так).
А мне, как разработчику кросс-платформенных приложений от появления ещё одного Direct3D, Metal, Mantle для конкретной платформы вместо кросс-платформенного стандарта или адаптации оного (как WebGL близок к OpenGL ES) никак не поможет.
Да, всё именно так — достаточно зайти на айфоне на WebGL Report страничку.
Думаю, если бы на iOS были бы альтернативы, то можно было бы и забросить эту затею с мучениями на WebGL 1.0, описанными в статье…
Хотя есть некоторые причины ожидать, что одной проблемой станет меньше с очередным крупным обновлением iOS.
Не знаю на счёт Khronos и какое они отношение имеют к WebGPU.
Да, всё время забываю, что для разработки web-стандартов есть свои консорциумы.
Поэтому WebXR получился непохожим на OpenXR, хотя одно и реализуется поверх другого и решает по сути те же самые задачи…
Баги — это отдельная тема. Что показывает конкретная демка не могу судить — у меня она ведёт себя одинаково на десктопе (Firefox) и телефоне (Android), поэтому скорее всего что-то не так с реализацией. Выглядит словно кто-то забыл отключить запись буфера глубины при отрисовке полупрозрачных объектов.
На Android разработчиков GPU прорва и у каждого свои драйвера со своими багами. Первые реализации OpenGL ES 3.0 на Android были жутко глючными, но со временем подтянули уровень. А на iOS — один вендор и только одно поведение.
Разумеется, чем меньше разнообразия, тем проще вести разработку (баги / не баги — не так важно, когда всё знакомо и ожидаемо, то и баги могут стать родными). Но и общаться с одним единственным вендором сложнее — он начинает диктовать свои условия, а замечания, что у него что-то не так просто игнорировать.
В обсуждениях Khronos упоминали, что первые WebGPU спецификации обещают закрыть к концу этого года. Сама история WebGPU достаточно любопытна — началось всё с попытки Apple выдвинуть его в виде WebMetal, очевидно на основе своего Metal, но коллеги не оценили и стали переписывать его в сторону Vulkan и с другим названием. При этом WebGPU не является калькой вулкана, а чем-то новым…
Поэтому было бы интересно, чтобы тот, кто варится в этих экспериментах WebGPU, рассказал какие очертания этот новый стандарт принимает на текущий момент, и на что же он на самом деле похож.
Как раз сейчас пытаются запускать подобные процессы (вроде "Epic Games против Apple", но там дело больше в жадности, нежели в борьбе за справедливость и свободы пользователей), но, очевидно, с очень большим запозданием.
Искусственные ограничения конкуренции и свобод пользователей были очевидны с самого запуска iPhone, и антимонопольные структуры должны были начать давить на Apple как только стало понятно, что их продукты стали массовыми.
Но тут есть и другие неудачные прецеденты, вроде тех же игровых приставок от Sony и Microsoft, таких же закрытых и навязывающих свои условия — практику, которую они ввели задолго до появления iOS…
То есть современный Chrome сейчас базируется на собственном форке движка WebKit, который развивается независимо. Поэтому Chrome на macOS нормально выдаёт WebGL 2.0.
Но это НЕ касается версии Chrome для iOS.
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).
это неправда, Rosetta предлагает установку при первом распознанном Intel-based приложении.
Я всего-лишь говорю о личном опыте: свежая система, установлены последние обновления, опробовано несколько приложений из архивов DMG (не через магазин — там-то Apple ясное дело должна была всё подготовить). Результат — приложения не запускались без каких-либо ошибок. Зачем мне кого-то обманывать?
Я пока не встречал аналога glxinfo для macOS, поэтому на скорую руку могу дать вывод списка расширений OpenGL из DRAWEXE (если интересует что-то конкретное — могу выцепить):
Ну во-первых, нативного Vulkan нет на платформе macOS (если говорить про виновника статьи).
Во-вторых, Vulkan не является полноправной заменой OpenGL, как бы многим не хотелось закопать старый графический API.
OpenGL гораздо проще для вхождения и не заставляет разработчика опускаться до специфичных для конкретного GPU особенностей. Может получиться более медленное приложение, но зато более кросс-вендорное. При этом преимущества по скорости могут быть и вовсе незаметными в конкретных случаях. То есть даже в случае написания нового приложения с нуля, выбор графического API пока остаётся неочевидным.
Но ведь WebGPU — это не новый графический API для всех, он разрабатывается с фокусом на браузеры (хотя по комментарию lain8dono у меня сложилось ощущение, что это не совсем так).
А мне, как разработчику кросс-платформенных приложений от появления ещё одного Direct3D, Metal, Mantle для конкретной платформы вместо кросс-платформенного стандарта или адаптации оного (как WebGL близок к OpenGL ES) никак не поможет.
Думаю, если бы на iOS были бы альтернативы, то можно было бы и забросить эту затею с мучениями на WebGL 1.0, описанными в статье…
Хотя есть некоторые причины ожидать, что одной проблемой станет меньше с очередным крупным обновлением iOS.
Да, всё время забываю, что для разработки web-стандартов есть свои консорциумы.
Поэтому WebXR получился непохожим на OpenXR, хотя одно и реализуется поверх другого и решает по сути те же самые задачи…
На Android разработчиков GPU прорва и у каждого свои драйвера со своими багами. Первые реализации OpenGL ES 3.0 на Android были жутко глючными, но со временем подтянули уровень. А на iOS — один вендор и только одно поведение.
Разумеется, чем меньше разнообразия, тем проще вести разработку (баги / не баги — не так важно, когда всё знакомо и ожидаемо, то и баги могут стать родными). Но и общаться с одним единственным вендором сложнее — он начинает диктовать свои условия, а замечания, что у него что-то не так просто игнорировать.
Поэтому было бы интересно, чтобы тот, кто варится в этих экспериментах WebGPU, рассказал какие очертания этот новый стандарт принимает на текущий момент, и на что же он на самом деле похож.
Искусственные ограничения конкуренции и свобод пользователей были очевидны с самого запуска iPhone, и антимонопольные структуры должны были начать давить на Apple как только стало понятно, что их продукты стали массовыми.
Но тут есть и другие неудачные прецеденты, вроде тех же игровых приставок от Sony и Microsoft, таких же закрытых и навязывающих свои условия — практику, которую они ввели задолго до появления iOS…
То есть современный Chrome сейчас базируется на собственном форке движка WebKit, который развивается независимо. Поэтому Chrome на macOS нормально выдаёт WebGL 2.0.
Но это НЕ касается версии Chrome для iOS.
Ну казалось бы — git-gui, куда-уж проще приложение?
Ан нет — Intel-версия падает при запуске (хотя gitk запускается).
В первый раз пришлось собирать git из исходных текстов!
Я всего-лишь говорю о личном опыте: свежая система, установлены последние обновления, опробовано несколько приложений из архивов DMG (не через магазин — там-то Apple ясное дело должна была всё подготовить). Результат — приложения не запускались без каких-либо ошибок. Зачем мне кого-то обманывать?
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
Во-вторых, Vulkan не является полноправной заменой OpenGL, как бы многим не хотелось закопать старый графический API.
OpenGL гораздо проще для вхождения и не заставляет разработчика опускаться до специфичных для конкретного GPU особенностей. Может получиться более медленное приложение, но зато более кросс-вендорное. При этом преимущества по скорости могут быть и вовсе незаметными в конкретных случаях. То есть даже в случае написания нового приложения с нуля, выбор графического API пока остаётся неочевидным.