Как обновить opengl на mac os
Обновлено: 04.07.2024
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.
Проблема совместимости со старыми приложениями при появлении новых платформ была актуальна не один раз. 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 версии CAD Assistant на macOS Big Sur (ARM)
Английская версия публикации может быть найдена по следующей ссылке.
Падения sView в момент масштабирования окна могут быть связаны с проблемами в обработке OpenGL из не-GUI потока (данная возможность была объявлена "устаревшей" в предыдущем обновлении macOS). Отключить отрисовку в отдельном потоке в sView можно специальным ключом:
I attempted to use Secondlife recently on my new MacBookpro. Avatars in the environment remain "naked" for quite a while. I submitted a screenshot of the problem to them as a bug report.
Thier reponse was that I need to upgrade OpenGL form 2.1 to 4.2
Any idea how to do this?
Never mind the entire issue that if a brand new MacBookPro cant use thier Gold Release Client software, then really.. who would be able to login to them anyway?
For your amusement, here is the current log of the conversation with their people at Linden Labs..
Status: Open
Priority: Unset
Resolution: Unresolved
Affects Version/s: None
Fix Version/s: None
Component/s: None
Labels:
Environment:
1/RELEASE_X86_64 x86_64 Graphics Card Vendor: Intel Inc. Graphics Card: Intel HD Graphics 3000 OpenGL Engine OpenGL Version: 2.1 APPLE-7.14.5 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v6.4.1 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 3.2.0002.10426 Built with GCC version 40001 Packets Lost: 2494/171041 (1.5%)
I looked around.. but the other clothing issues did not appear exactly or nearly like this one.
I havent used SL for quite a while.. and I am starting to remember why.. but since Sony now has their virtual area.. it reminded me of the advantages of SL.. so I circled back around and tried to get back inthe groove.
My avatar is mangled. My skin is not visible.. most of my clothing will not work. My old avi was basicall stripped naked when I logged into this 3.5.2 viewer on Mac.
I tried to "reboot" the avi by just picking a stock avi..
Only a few of the clothes will show, the skin is invisible. Many other Avatar items will not display.
I went thru the blogs on how to change clothes.. and this was no help.. this is probably a bug.
I am using Mac OSX10.17 on MacBookPro.. a BRAND NEW (2mos old) Mac..
so.. it should NOT be a video issue..
If it is.. then who is managing SL's marketing that a brand new high end laptop cant access your services.
My avatar is Jebediah Raymaker
Theresa Tennyson added a comment - 01/Feb/12 3:21 PM
Second Life uses an open graphics language called OpenGL. The current version of OpenGL is 4.2 and OpenGL was heavily revised around Version 3. Right now Second Life sees your MacBook as having Intel graphics that only supports OpenGL 2.1. Does your MacBook have automatic switching between integrated graphics and a dedicated Nvidia or ATI GPU, and if so, can it be disabled? A lot of people with laptops with auto-switching graphics have problems with OpenGL programs.
Jebediah Raymaker added a comment - 01/Feb/12 8:59 PM
I really have no idea whether or not that is even a good idea to try it. This is a BRAND NEW MacBookPro (2 months old).
At the end of the day, if SLs client software is so advanced that even a very well provisioned, brand new top of the line MacBookPro can not reliably run your software, then perhaps SL is riding the bleeding edge a bit too much. After all, it is not as if I am riding on a rusty and dusty old nag of a laptop I resurrected form the pits of my basement!
I have always wondered why more people havent adopted the SL model, since it affords so many innovative possibilities. However, if this is mantra of your company, to produce client software that prevents users that possess even the top of the line hardware to access your services.. then.. the answer is clear to me.
Thanks anyway, but I really have lot more productive things to do besides spend a few hours figuring out how to give my OpenGL drivers a lobotomy just so I can frolic in a digital environment. I would be better off getting my work done, and going outside and enjoying some fresh air!
I will try again next year and see if the SL client software has become.. less "elitist" (such a popular critical word these days.. thought I would roll it out! Hopefuly you will still be in business?
Mac OS 10.14 Mojave was just released, and since June, we've known that OpenGL was to be deprecated in the OS. "OpenGL applications will continue to run, but you should switch to Metal," to paraphrase. However, there doesn't seem to be any documentation indicating whether you can still compile with OpenGL or if Apple prevents that or omits the proper development libraries. I am currently developing an OpenGL-based graphics program and cannot risk updating if compilation will no longer work. Has anyone tested this?
EDIT: Does anyone else share Esenthel's experience?
11 Answers 11
I can compile, however after updating to latest Mojave and Xcode, my OpenGL applications simply don't work.
I recommend that you don't update.
I think there's something broken in Xcode 10 OpenGL libraries.
Edit: It appears that later Mac OS and Xcode updates have fixed the problems.
I still need to set-up tools on high sierra (the hardware shipped with that OS). Can I still get XCode 9 on there? I confirm that after updating to Mojave 10.14.3 and Xcode 10.1 this issue has been fixed. No need to do the little hack for making this code run.GLFW work around. Similar to other answers, but you do not need to resize your window in the draw loop, just call glfwPollEvents() first.
Also, glfwHideWindow() then glfwShowWindow() seems to work. Similarly glfwSetWindowPos() is an alternative. Though setting the window size seems faster than hide/showing the window, and I don't want to move the window position.
works fine in Mojave with Xcode 10.0. The window is resized automatically to get rid of the black. OpenGL and GLUT frameworks are added to the project from the usual place, /System/Library/Frameworks
I'm using GLEW, GLUT, OpenGL 2.0 and SDL 2. I can compile and run my OpenGL application. However I had to change my Framework Search Paths to include:
where OpenGL and GLUT framework + headers are now placed as I couldn't find any OpenGL/GLUT headers in the old search path System/Library/Frameworks (although the framework was still there, no headers were included). I also had to make sure my includes were GLUT/glut.h instead of just glut.h.
This gives me new warning messages in form of:
[default] Unable to load Info.plist exceptions (eGPUOverrides)" and "saved enable noise cancellation setting is the same as the default (=1)
I haven't checked them yet, and what their implications are.
What really bugs me is what Esenthel says, that there is just a black screen after compiling and running the app. I found that if you drag the app window (I'm not using full screen) then the animation starts to show. Apparently the animation is in the background and all code is evaluating, but there is only a black screen until I drag the window.
Из презентации Apple
Компания Apple обновила документацию для разработчиков. Раздел «Что нового?» посвящён ключевым изменениям в macOS 10.14: это тёмная цветовая схема Dark Mode, новая технология Create ML для создания и обучения нейросетей на Mac, обновлённый Mac App Store с новыми программными интерфейсами для рейтингов и обзоров (под macOS 10.14 SDK), новый сетевой фреймворк Network Framework, предоставляющий прямой доступ к сетевым протоколам TLS, TCP и UDP из приложений, фреймворк Natural Language для анализа естественной речи и вычленения из неё метаданных, специфических для конкретного языка (фреймворк можно использовать совместно с Create ML при обучении нейросетей).
Но самое интересное спрятано в подвале, а именно в разделе «Устаревшие и удалённые API» (Deprecations and Removed APIs). Там упоминается об отказе от «устаревших» технологий OpenGL и OpenCL. Этим технологиям вручается «чёрная метка», то есть Apple настоятельно не рекомендует использовать OpenGL и OpenCL в разработке новых продуктов.
«Периодически Apple добавляет макросы устаревания в API, чтобы указать, что эти API не должны больше использоваться в активной разработке, — сказано в документации. — Когда происходит устаревание, это не означает немедленного окончания жизни указанных программных интерфейсов. Это означает начало переходного (grace) периода для перехода от этих API к более новой и современной альтернативе, которая приходит на замену».
Apple отмечает, что устаревшие API обычно остаются в системе и могут использоваться в течение «разумного времени» после релиза, когда их объявили устаревшими. Однако активная разработка на них прекращается, и API получают только незначительные обновления безопасности или других критических ошибок. Разработчиков предупреждают, что устаревшие API могут быть полностью удалены из будущей версии операционной системы.
Apple рекомендует как можно скорее избавиться от устаревших API в своём коде. Как минимум, новый код ни в коему случае не должен использовать OpenGL и OpenCL. И если эти интерфейсы использует какой-то старый код, то его нужно заменить максимально быстро.
Приложения, созданные с использованием OpenGL и OpenCL, будут продолжать работать в macOS 10.14, но это уже устаревшие технологии. «Игры и графические приложения, использующие OpenGL, теперь должны использовать Metal. Точно так же приложения, использующие OpenCL для вычислительных задач, теперь должны использовать Metal и Metal Performance Shaders».
Metal — разработанные с нуля новые программные интерфейсы, лишённые обратной совместимости. По заявлению Apple, они обеспечивают лучший доступ к современным графическим процессорам на iOS, macOS, а также устройствам tvOS: «Metal позволяет избежать накладных расходов, присущих устаревшим технологиям и представляет новейшие функции обработки графики. Единая поддержка графики и вычислений в Metal позволяет приложениям эффективно использовать новейшие технологии визуализации. Сведения о разработке приложений и игр с использованием Metal см. в документации для разработчиков по Metal, Metal Performance Shaders и MetalKit».
Информация о миграции кода OpenGL на Metal опубликована в статье Mixing Metal and OpenGL Rendering in a View.
Разработчики на Hacker News скептически оценивают действия Apple. В целом консенсус такой: эта компания или действительно ненавидит компьютерные игры, или жестоко страдает от синдрома неприятия чужой разработки (NIH-синдром). Это позиция в социальной, корпоративной или организационной культурах, при которой избегается использование сторонних разработок по разным причинам: страх перед нарушением патентного права, непонимание чужой работы, нежелание признать или оценить труд других, ревность или как часть более широкой «войны за территорию». Якобы технология Metal подтверждает наличие NIH-синдрома.
Комментаторы также напоминают, что из-за безалаберной поддержки OpenGL недавно пришлось закрыть проект Elite Dangerous под Mac.
С другой стороны, сегодня большинство игр создаётся на Unity3D, Unreal Engine и других движках, которые поддерживают Metal. Ну а кто вложил время и деньги в разработку под OpenGL/OpenCL — тот сам виноват.
Читайте также: