floooh / sokol

minimal cross-platform standalone C headers
https://floooh.github.io/sokol-html5
zlib License
6.53k stars 467 forks source link

Questions regarding default GL version #1068

Open Wertzui123 opened 1 week ago

Wertzui123 commented 1 week ago

Hello floooh,

I've got a couple of questions regarding the default GL version when using the GLCORE graphics backend. Please note that I'm not too familiar with graphics APIs, so what I ask might be stupid. 😅

First of all, what even is the default GL version? https://github.com/floooh/sokol/blob/master/sokol_app.h#L1711 says it's 3.2, but this code https://github.com/floooh/sokol/blob/master/sokol_app.h#L3103 seems to default it to 4.3. I guess the first comment is a typo (or hasn't been updated properly), because when manually setting the value to 3.2, sokol_app works on my VM machine, whereas if I leave it at the default, it doesn't.

Secondly, are these versions normally backwards compatible? So for example, when I set the default to 3.2, will it reliably also work on modern systems that might already have a newer version?

And finally, what are some good reasons why someone might want to use the GLES3 backend instead of the GLCORE backend on Linux? Or is it generally advised to use the GLCORE backend (which seems to be the default)?

Kind regards, Wertzui123

floooh commented 1 week ago

says it's 3.2

...oops that's a left-over which I forgot to update.

In general, sokol_gfx.h now expects either desktop GL 4.1 on macOS or 4.3 on other platforms, the GLES "sub-backend" expects GLES 3.0.

These are also the default GL versions initialized by sokol_app.h (although for desktop GL you can also request a more recent version, sokol_gfx.h just won't make use of any features later than 4.3).

The split between 4.1 and 4.3 is an unfortunate side effect of macOS only going up to 4.1, but wanting to have storage buffer support (and eventually compute shader support) on desktop platforms that are not limited to GL 4.1.

Currently, the "non-storage-buffer" code path in sokol_gfx.h might still work with GL 3.x, but this will not be guaranteed (actually using 4.1 features would allow to support the features mrt_independent_blend_state and mrt_independent_write_mask in the desktop GL backend (see sg_features).

It's possible to use GL 4.1 on non-macOS platforms, but in that case the storage buffer feature will be disabled.

More details are in this blog post: https://floooh.github.io/2024/05/06/sokol-storage-buffers.html

And finally, what are some good reasons why someone might want to use the GLES3 backend instead of the GLCORE backend on Linux?

IIRC this was an outside feature request, not sure if for debugging mobile or WebGL code, or whether there are Linux distros that only support GLES3 (maybe on some embedded platforms?).

Out of interest, what's the latest GL version your VM supports?

Secondly, are these versions normally backwards compatible? So for example, when I set the default to 3.2, will it reliably also work on modern systems that might already have a newer version?

There are no clear API separations between different GL versions unfortunately, so GL versions are generally backward compatible. 3.2 might stop working once sokolgfx.h gets support for those two `mrt*` features I mentioned above, but if 3.x is still important we can keep those features as optional.

But I'd like to keep the number of runtime-optional features as low as possible, and GL 4.1 is 14 years old by now, so dropping support for 3.x shouldn't be all that controversial hopefully.

Wertzui123 commented 1 week ago

Thanks a lot for the detailed answer!

It looks like the max version my current Mesa installation supports is 3.1:

$ glxinfo | grep "OpenGL version"
OpenGL version string: 3.1 Mesa 18.3.6

The VM is running on Debian 10, so I doubt there's no way to get OpenGL 4.1, if it's actually, as you say, 14 years old already. 🤔 But I haven't figured out the command yet (sudo apt-get install --only-upgrade mesa-utils libgl1-mesa-dri libgl1-mesa-glx libglfw3-dev did upgrade some packages but didn't change the Mesa/OpenGL version).

Wertzui123 commented 1 week ago

or might this be related to some old drivers on my actual OS/hardware?

floooh commented 1 week ago

Maybe the VM only implements an outdated virtual GPU which doesn't expose the features required for GL 4.x.

Wertzui123 commented 1 week ago

That might be the reason, yeah, but I can't seem to get it to update to a newer one. I've tried installing Guest Additions in VirtualBox, but it doesn't seem to change anything. Enabling 3D acceleration prevents me from logging in (after typing in the password, it just waits for a few seconds and then goes back to the login screen). I'll try to fix it again tomorrow, but if someone has any tips, please let me know.