LukasBanana / LLGL

Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal
BSD 3-Clause "New" or "Revised" License
2.05k stars 139 forks source link

What's the minimum OpenGL version supported? #58

Closed beldenfox closed 1 year ago

beldenfox commented 4 years ago

I couldn't find any statement on the minimum version of OpenGL that LLGL is written for. While working with the sample Cpp programs I noticed that LLGL always enables GL_TEXTURE_CUBE_MAP_SEAMLESS which is a 3.2 feature and GL_PRIMITIVE_RESTART_FIXED_INDEX which is a 4.3 feature. On earlier versions either of these calls could cause an INVALID_ENUM error to be logged.

Since the OpenGL on the Mac is frozen at version 4.1 GL_PRIMITIVE_RESTART_FIXED_INDEX doesn't work. I'm trying to re-implement this using GL_PRIMITIVE_RESTART but that requires a minimum version of 3.1. Can 3.1 features be invoked unconditionally?

LukasBanana commented 4 years ago

That's a good point, some of those GL states might cause undefined behavior. With the CMake option LLGL_GL_ENABLE_OPENGL2X, you could theoretically go back to GL 2.x, but that was only a small experiment to have a fallback when VAOs were not supported on one of my Linux VMs. It only enables the class GL2XVertexArray. LLGL was designed with at least GL 3.x in mind.

beldenfox commented 4 years ago

The calls that enable features are piecemeal and so it shouldn't be too much trouble to surround them with appropriate version guards. The problem area is the loop that calls glIsEnabled(). This is a convenient and maintainable way of querying the current state of the system but unsupported values will cause a GL_INVALID_ENUM error to be logged. One solution is to ditch the loop and break this out into a bunch of version-protected glIsEnabled calls. The other is to keep the loop but clear the error state out at the end since errors logged by glIsEnabled are benign. FWIW I don't like either solution.

What's your position on run-time version compile-time checks? On the Mac the OpenGL version is 4.1 at compile-time but at run-time a client can request a 3.2 context. I'm not sure how common this is on other platforms.

LukasBanana commented 4 years ago

I guess you're right about the loop over glIsEnabled. Compile-time checks are not great for platforms other than Mac, since MacOS only supports 3 version of GL: 2.0 "legacy", 3.2 and 4.1. For all other platforms, I'm handling most of the feature support by run-time checks for extension support. I.e. an older GL version can be requested, but some systems might still support some of the newer extensions. As long as the respective extension is present in the GL context, it should be safe to use it.

In some case, however, I'm using both a version guard and a run-time check. The version guard is primarily for MacOS, where the respective macros and functions are not even declared. Take a look at DrawIndirect for instance.

LukasBanana commented 1 year ago

Better late than never: This should be fixed now with 0f0be3a. The minimum required GL version is supposed to be 2.0, which requires LLGL_GL_ENABLE_OPENGL2X to be enabled in CMake.