Is there an option with Lazarus own board means to activate the OpenGL 3.3 core mode. Or is it enough for me to do the following?

   OpenGLControl.OpenGLMajorVersion := 3;
   OpenGLControl.OpenGLMinorVersion := 3;

Mfg Mathias

2017-05-21 22:38 GMT+02:00 Mathias :

These TOpenGLControl properties are passed to the underlying API to indicate that you want a context that supports this specific OpenGL version. So, yes, this is the way to get OpenGL 3.3 context.

However, it's not implemented on all platforms. As far as I see, only the GTK widgetset actually uses the Major/MinorVersion, other widgetsets simply ignore it.

But in practice, you will also get a 3.3 context without requesting it, if your OpenGL supports it, and it has ARB_compatibility. See https://www.khronos.org/opengl/wiki/Core_And_Compatibility_in_Contexts about the gory details.

Regards,
Michalis

The biggest problem you may have with this is requesting a post 2.1 context in Mac OS X since Apple decided to create a schism in versioning and only supports either 2.1 and below or 3.2 core and above. They do not have ARB_compatibility.

Same with Mesa, meaning that on Linux you can use either 2.1 and below or 3.x core and above if you use the AMDGPU or Intel drivers (AMDGPU-Pro and of course Nvidia drivers support the entire OpenGL).

From a quick look at the source, for Mac OS X only the Cocoa backend

supports versioning and for Linux only GTK (Qt doesn't).

Note that there is no explicit way with TOpenGLControl to request the profile, meaning that under GLX (Linux, GTK2) you always get the core profile (as per the GLX_ARB_create_context spec) *unless* you ask for 3.0 or less and you *may* get a compatibility profile you 3.1. With 3.2 you always get core.

This is a cross-platform issue since if you specify a post 3.2 or above profile in Windows, Carbon or Qt you do not get a core profile but a compatibility one (in Carbon and Qt you will get a 2.1 profile in some GPU drivers - like AMDGPU and Intel - even if you ask for a 3.2 since the requested version is ignored and these drivers do not support compatibility profiles). This means that if you accidentally use deprecated functionality and you develop under Windows you wont notice it until you try the program under Linux or Mac OS X. Also it can be a performance issue since IIRC Nvidia has said that requesting a core profile will make the driver do extra checks to make sure you are not using deprecated functionality.

I think the control should gain a Profile attribute to solve this. And while at it, also a ForwardCompatible attribute for debugging (forward compatible contexts disable any deprecated functionality, but they can also slow down rendering due to extra tests, so they are only good for debugging code).

On Fri, May 26, 2017 at 12:51 PM, Michalis Kamburelis <

[...] I think the control should gain a Profile attribute to solve this.

How would that "Profile attribute" look like?

Mattias

I'd use an enum with values like (glcDefaultProfile, glcCoreProfile, glcCompatibilityProfile). Default would leave things as-is (when versioning is introduced to backends that currently do not support it, it will either use a backend-specific default or leave it unspecified where possible), Core will explicitly request a core profile and Compatibility will explicitly request a compatibility profile. Under OSes where compatibility isn't available, the context creation would fail.

For bonus points, i'd rename glcCoreProfile to glcRequireCoreProfile and instead of glcCompatibilityProfile i'd use glcPreferCompatibilityProfile and glcRequireCompatibilityProfile. glcRequireCoreProfile would work like above, glcPreferCompatibilityProfile will first try to use the compatibility profile but fallback to core if not available (so that the drivers avoid the extra checks) and glcRequireCompatibilityProfile will fail if the compatibility profile doesn't exist - basically having the profiles as glcDefaultProfile, glcPreferCompatibilityProfile, glcRequireCompatibilityProfile and glcRequireCoreProfile.

On Fri, May 26, 2017 at 6:40 PM, Mattias Gaertner <

2017-05-26 18:48 GMT+02:00 Kostas Michalopoulos :

I like all of these ideas:)

And they are easily implementable by
https://www.khronos.org/registry/OpenGL/extensions/ARB/GLX_ARB_create_context.txt (used by the GTK implementation):

- glcRequireCoreProfile and glcRequireCompatibilityProfile results in the appropriate bit set of GLX_CONTEXT_PROFILE_MASK_ARB .
- glcPreferCompatibilityProfile would need to eventually query for another profile, as you write (I'm not sure do we really need it much? I see that sometimes it can be useful, if the implementation can adapt to use either "old fixed-function renderer" or not, but I'm not sure is this a large need.)
- ForwardCompatible = true sets the
GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB bit in GLX_CONTEXT_FLAGS_ARB .

Not that I'm volunteering to implement them (I'm not having much time, and I mostly use my own OpenGL context creation in CastleWindow). But it makes sense and I would gladly test it:)

Regards,
Michalis