GL 4 Progress and Help

[AF]

The current MacOS status makes me sad and I feel a bit lost in figuring out how I can help

My current theory is that if I check out the develop branch and try to build then I can run it and see how far it gets before a pre OpenGL4 system gets in the way ( likely immediately ). Is this correct? Or do i need to mess around with contexts first?

Right now I'm needing to scratch my RTS itch elsewhere and it wont even run in Wine

[MasterBel]

Last time I tried to compile for MacOS: runs into an OpenGL include problem and crashes at about 70%. Afaik it's the only issue in the compile. In the MacOS thread I put a package that should help you set up the environment for the compile. I can't garuantee it works out of the box but it's supposed to (something like that is hard to test)
I'm about to go back to giving building a shot and trying to work out what the issue is but all previous attempts to solve the build issue failed.

[PicassoCT]

Its spring beeing out of touch eversince the bar project frooze. Butt with your work spring can live again on the touchbar.

If steve could see this debacle apple has turned into.. He would go on a killing spree.

[Kloot]

Apple dropped OpenGL like a rock after 4.1-core in favor of their Metal API and we don't exactly have the resources to implement a nice abstraction layer that can speak both dialects.

The only thing to do is wait or contribute code.

[PicassoCT]

Metall starts to look like one huge way to shift the burden of implementation away from the driver implementors.

[Kloot]

Yes and no, Metal/Vulkan are just the result of the AAA game industry (where people *want* the ability to write what are essentially mini-drivers) pushing for more control over performance.

Hobbyist projects don't dictate tech developments.

[PicassoCT]

But hobbyists and academics can bring forth standardization- so that work is not done a dozzen times over.
This seems like a lot of wheel reinventing is about to happen.

[Super Mario]

Yes and no, Metal/Vulkan are just the result of the AAA game industry (where people *want* the ability to write what are essentially mini-drivers) pushing for more control over performance.

In order to obtain more peformance. Though Valve made MoltenVK opensource which is itself interesting to look at during your spare time.

[AF]

Plenty of OpenGL stuff still runs on MacOS, I thought the goal was to move spring towards OpenGL 4.1 core? The situation may not be optimal but OpenGL as an API isn't going away anytime soon on MacOS.

So with regards to GL 4.1 progress, what's the current status? Are there blockers, what's next on the chopping block for refactoring/conversion? Anything good for new contributors to help out with?

[AF]

I've done some searching and it seems the closest I can find to an actual table of GL extensions/functions and their versions is the grid over at https://mesamatrix.net/

With that in mind, how useful would a spreadsheet with these down the side, and GL Version across the top be? It might take some work but a proper list of what needs doing would be helpful in coordinating people. Right now the effort is a little bit of a blackbox

[ivand]

Since apparently @Kloot does almost full rework of graphical part of the engine/API, maybe it makes sense to look into some multirender backend libs, like:

https://github.com/bkaradzic/bgfx

[AF]

One of the problems there is that every lua widget would need rewriting. A good chunk of stuff would need updating with A GL4 engine but not nearly as much.

I did see that the GLBindings project makes it easier to wrangle these things, but adding a dependency and switching everything over to the GLBindings wrapper isn't a 5 minute job and do we really need another wrapper?

My current thinking is to clone the repo and search for all instances of `gl`, and put them in a spreadsheet, and mark which version of the GL spec is needed for that, flagging anything lower than 4

[ptstart]

This is how I catch removed features in the 4.5 core profile:

- Have this in the spring settings file:
DebugGL = true
DebugGLStacktraces = true
ForceCoreContext = 1

- have MESA_GL_VERSION_OVERRIDE = 4.5 in env if need be, with export MESA_GL_VERSION_OVERRIDE=4.5 (it still reads your compatibility profile version, even if you set ForceCoreContext = 1. Is this a bug?)

- make sure to comment out the extension checks (located in GlobalRendering.cpp)

- Open spring in gdb and set a breakpoint on the opengl debug callback function (located in GlobalRendering.cpp, roughly line 1330 if I recall)

This will catch removed features from the core profile, but not deprecated ones I don't think. This method only works on Linux I think as well

[MasterBel2]

This is how I catch removed features in the 4.5 core profile:

- Have this in the spring settings file:
DebugGL = true
DebugGLStacktraces = true
ForceCoreContext = 1

- have MESA_GL_VERSION_OVERRIDE = 4.5 in env if need be, with export MESA_GL_VERSION_OVERRIDE=4.5 (it still reads your compatibility profile version, even if you set ForceCoreContext = 1. Is this a bug?)

- make sure to comment out the extension checks (located in GlobalRendering.cpp)

- Open spring in gdb and set a breakpoint on the opengl debug callback function (located in GlobalRendering.cpp, roughly line 1330 if I recall)

This will catch removed features from the core profile, but not deprecated ones I don't think. This method only works on Linux I think as well

Please note that we're using 4.1 not 4.5 since 4.1 is the latest Core profile supported by MacOS (and 2.1 is the latest Compatability profile, iirc)?

[Super Mario]

Apple dropped OpenGL like a rock after 4.1-core in favor of their Metal API and we don't exactly have the resources to implement a nice abstraction layer that can speak both dialects.

The only thing to do is wait or contribute code.

Are you open to the possibility of relying of an external framework for graphics api instead of your own? At the very lest when it comes to mac?

[AF]

hmm that's handy. Even if we can't get MacOS builds working, we can at the very least sort out the OpenGL ones and get Wine working. Hopefully I can crosscompile a windows binary from a docker container/VM/VPS

[PicassoCT]

Kloot- is there a way we can prepare our games for the upcoming version of the engine?

[sanguinariojoe]

I reopen this topic

Kloot, In which point is the GL 4.1 transition? How can we contribute?

As far as I can see, in GlobalRendering.cpp GL 3.X contexts are still created (and considered valid) in Linux systems. The engine is working fine with NVidia privative drivers, but in AMD is obviously failing while compiling some shaders (which requires GL 4.1).
On the other hand, If I enforce a core profile generation (setting GLContextMajorVersion=4, ForceCoreContext=1), then everything is collapsing because Stencil buffer is required:

Code: Select all

	if (!CheckGLStencilBufferBits(8)) {
		handleerror(nullptr, "insufficient OpenGL stencil-buffer support, aborting", "ERROR", MBF_OK | MBF_EXCL);
		return false;
	}

I can easily modify GlobalRendering.cpp to can launch the engine with a GL >=4.1 core profile context. But it would be great to get first some feedback from you, Kloot

[sanguinariojoe]

I tested the AMD graphica card again, enforcing a GL 4.1 core profile context, and everything worked fine (it has crashed later during a game load due to a LUA error)

Summarizing (all in Linux):

NVidia, default settings (GL 3.0) = Working fine
NVidia, enforcing GL 4.1 core = Fail (No Stencil support)
AMD, default settings (GL 3.0) = Fail (GL >= 4.1 Shader requirement)
AMD, enforcing GL 4.1 core = OK

[MasterBel2]

Could this in any way be related to the macos build fail which iirc (I can't check rn) fails in global rendering. Cpp?