OpenGL context and macOS

OpenGL context and macOS

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
Belmakor
Posts: 212
Joined: 16 Nov 2005, 00:01

OpenGL context and macOS

Post by Belmakor »

Ok, I'm bringing this here from the thread in the Mac OS X forum: viewtopic.php?f=65&t=36428

Basically, 104.0 is failing to create the GL context on mac OS.

Best I can tell is that the required compatibility context is not supported by mac OS, and so the function CGlobalRendering::CreateGLContext in rts/Rendering/GlobalRendering.cpp fails.

Not fully understanding the setup, I'm looking for advice from the engine devs as to the appropriate change to make. Basically, macOS supports creating a GL core context in 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0 and 4.1. The only compatibility contexts it creates are 2.0 and 2.1. I'm guessing that Spring is trying to create a 3.1 compatibility context and fails.

So I would love to know the appropriate patch to apply to GlobalRendering.cpp in order to get the appropriate GL context to be created so I can play with the new version on Mac OS X.
User avatar
Belmakor
Posts: 212
Joined: 16 Nov 2005, 00:01

Re: OpenGL context and macOS

Post by Belmakor »

Ok, last thing… I decided to just comment out various stuff in that file which looks for the available context versions, and just forced the creation of a core 3.1 context. Discovered that when you ask for a core context, you always get the latest available (for my Mac, GL 4.1), not the one you ask for, and now I get a new error on launch:

Code: Select all

Error: [ExitSpringProcess] errorMsg="Needed OpenGL extension(s) not found:
   GL_ARB_texture_env_combine

Update your graphics-card drivers!
  Graphics card:  NVIDIA GeForce GTX 680MX OpenGL Engine
  OpenGL version: 4.1 NVIDIA-10.17.5 355.10.05.45f01
" msgCaption="Spring: caught unsupported_error: " mainThread=1
Error: [Watchdog::ClearTimer(id)] Invalid thread 3 (_threadId=0x0)
I would be most welcoming of any ideas :)
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: OpenGL context and macOS

Post by Kloot »

What would you be if you were attached to another object by an inclined plane, wrapped helically around an axis?

Requesting a core context is not an option yet, but you can change the 3's to 2's on line https://github.com/spring/spring/blob/d ... ng.cpp#L31 to downgrade the requirement. Do this at your own risk, it voids any and all warranty if you encounter graphics-related glitches or crashes.

Also complain to Apple about their GL implementation, loudly.
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: OpenGL context and macOS

Post by Anarchid »

Going by the names alone, shouldn't ForceCoreContext help here?
User avatar
MasterBel2
Posts: 347
Joined: 11 Apr 2016, 12:03

Re: OpenGL context and macOS

Post by MasterBel2 »

I'm not sure of the exact change (I know he didn't use ForceCoreContext) Belmakor forced use of OpenGL 2.1, disabled check for minimum context, and now Spring starts with this error:

Code: Select all

[f=-000001] [Sound]   Devices:
[f=-000001] [Sound]     [Built-in Output]
[f=-000001] [CrashHandler] Error: Segmentation fault: 11 (SIGSEGV) in spring 104.0
[f=-000001] [CrashHandler] Error: Halted Stacktrace for Spring 104.0 using libunwind:
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (100.0ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (200.4ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (300.5ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (400.6ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (500.7ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (600.8ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (700.9ms)
[f=-000001] [CrashHandler] Error: [00]   CrashHandler::HaltedStacktrace(std::string const&, __siginfo*, __darwin_ucontext*) (in spring) + 94
[f=-000001] [CrashHandler] Error: [01]   CrashHandler::HandleSignal(int, __siginfo*, void*) (in spring) + 323
[f=-000001] [CrashHandler] Error: [02]   2   libsystem_platform.dylib            0x00007fffc3499b3a _sigtramp + 26
[f=-000001] [CrashHandler] Error: [03]   CSound::GetMaxMonoSources(ALCdevice_struct*, int) (in spring) + 100
[f=-000001] [CrashHandler] Error: [04]   CSound::InitThread(int) (in spring) + 1097
[f=-000001] [CrashHandler] Error: [05]   CSound::UpdateThread(int) (in spring) + 143
[f=-000001] [CrashHandler] Error: [06]   Threading::ThreadStart(std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*) (in spring) + 145
[f=-000001] [CrashHandler] Error: [07]   std::thread::_Impl<std::_Bind_simple<std::_Bind<void (* (std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*))(std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*)> ()> >::_M_run() (in spring) + 48
[f=-000001] [CrashHandler] Error: [08]   0x0001cdab (in libstdc++.6.dylib) + 48
[f=-000001] [CrashHandler] Error: [09]   9   libsystem_pthread.dylib             0x00007fffc34a393b _pthread_body + 180
[f=-000001] [CrashHandler] Error: [10]   10  libsystem_pthread.dylib             0x00007fffc34a3887 _pthread_body + 0
[f=-000001] [WatchDog::DeregisterThread] deregistering controls for thread [audio]
[f=-000001] Error: [ExitSpringProcess] errorMsg="Spring has crashed:
Segmentation fault: 11 (SIGSEGV).
Also: what would it take to get Spring working in a core context rather than a compatability context?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: OpenGL context and macOS

Post by Kloot »

A whole lot of work that is at least one major engine release away from being done.

Trace points to an OpenAL initialisation failure of some kind, no idea about the specifics.
User avatar
Belmakor
Posts: 212
Joined: 16 Nov 2005, 00:01

Re: OpenGL context and macOS

Post by Belmakor »

Kloot wrote:A whole lot of work that is at least one major engine release away from being done.
Any pointers? I'm guessing that trying to force 2.1 on the macOS version of the Spring Engine is a fool's errand, anyway - surely there is a reason why 3.1 was made the minimum, because the engine is using 3.1-only features?

I've since found this quote on the Khronos website here: https://www.khronos.org/opengl/wiki/OpenGL_Context
Platform Issue (MacOSX): When MacOSX 10.7 introduced support for OpenGL beyond 2.1, they also introduced the core/compatibility dichotomy. However, they did not introduce support for the compatibility profile itself. Instead, MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.
Does Spring rely on the Fixed Function Pipeline (whatever that is) at all?

Is it possible to roll back the requirement for 3.1?

Is it theoretically possible (given time/resources) to write a completely new rendering pipeline (e.g. based on Apple's Metal API) for Spring optimised for macOS and still be able to play the existing mods like BA, etc? Or is too much of the content tied to GL for this to be possible?
Trace points to an OpenAL initialisation failure of some kind, no idea about the specifics.
Alas, I haven't had time to follow this one up yet. Any other macOS people tried to get 104 working at all?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: OpenGL context and macOS

Post by Kloot »

Does Spring rely on the Fixed Function Pipeline (whatever that is) at all?
It does, as well as on GL3+ features. This is what makes Apple's decision to forego compatibility profiles problematic.
Is it theoretically possible (given time/resources) to write a completely new rendering pipeline (e.g. based on Apple's Metal API) for Spring optimised for macOS and still be able to play the existing mods like BA, etc?
Theoretically you can simulate every particle in the universe, but I'm more concerned with what can be achieved under realistic real-world bounds. The fact that we still do not even have a *compiling* (let alone maintained) MacOS autobuild should give you a pretty clear idea as to the answer here: someone with the right combination of skills, motivation, and free time *could* write a Metal backend (after fixing all other errors first), it is just extremely unlikely to ever happen. Until 105 arrives, your best option would be to step outside Apple's little walled garden and dual-boot to Linux.
MaDDoX
Posts: 77
Joined: 08 Jan 2006, 17:45

Re: OpenGL context and macOS

Post by MaDDoX »

Kloot, what exactly will change between 104 and 105 that will allow the OSX version to be compilable again - and why?
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: OpenGL context and macOS

Post by hokomoko »

Fixed Function Pipeline code will be removed, so compatibility mode won't be necessary. With core context, at least graphics should pose less of a problem.
Post Reply

Return to “Engine”