• March 09, 2021, 12:05:12 PM

Login with username, password and session length

Author Topic: (Solved) OpenGL Core Profile  (Read 1180 times)

0 Members and 1 Guest are viewing this topic.

Offline 3DickUlus

  • Administrator
  • *******
  • Posts: 2066
    • Digilantism
(Solved) Re: OpenGL Core Profile
« Reply #15 on: May 24, 2018, 09:47:20 PM »
Would probably require restart on change, none the less, will look at your fork and do some testing after work today.

Offline 3DickUlus

  • Administrator
  • *******
  • Posts: 2066
    • Digilantism
Re: OpenGL Core Profile
« Reply #16 on: May 26, 2018, 06:31:10 AM »
ok did some testing...

desired GL version selected in preferences and saved, restart FragM

construct a QGLFormat object (as mentioned in FragM source in an earlier post)
before creating the engine using the QGLFormat object, output to console the selected GL version

> "GL vers 1.1 requested."

after creating the engine, output to console the actual GL version used in the engine...

Code: [Select]
    qDebug() << QString("GL vers %1.%2 created.").arg(engine->context()->format().majorVersion()).arg(engine->context()->format().minorVersion());
> "GL vers 4.5 created."

One of the implied advantages of using v3+ core profile is vertex arrays and vertex buffer objects, but FragM only draws 1 triangle with 3 vertices so I don't think it's an advantage for the current setup.

Quote from the link you provided "This is known to work under Linux but Windows and macOS have some issues inside of Qt for creating Core Profile contexts."

When we set the version and profile in the frag code it then strictly enforces the version in the compiler parser and throws errors for deprecated commands and syntax

I would still like to recreate FragM using modern stuff like QGLSurface and friends...

edit: ..while retaining legacy functionality, after a little more hacking added profile and version to preferences dialog, crashes on core profile :( so I t must be setting profile properly, Qt's default is compatibility so all versions valid? core fails for the reasons you mention glBegin() etc. will have a look at your fork soon.
« Last Edit: May 26, 2018, 07:54:34 AM by 3DickUlus »

Offline 3DickUlus

  • Administrator
  • *******
  • Posts: 2066
    • Digilantism
Re: OpenGL Core Profile
« Reply #17 on: June 16, 2018, 08:40:25 AM »
I have created a branch on github named runtime-profile-version that has the changes from that diff I sent you.

from the command line...
  -g, --glversion <glversion>  GL version to use for main display.
                                eg: 4.1
  -p, --glprofile <glprofile>  GL Profile to use for main display.
                               Possible values are 'compat', 'core', 'none'

settings can be found in menu Edit->Preferences

suggest running from console for debug output.

not sure if this is 'proper' but it seems to work. In Qt all lower versions of GL are subsets of the highest version available, so, if a binary is compiled on a machine that supports 4.6 compat it should be able to run on a machine that supports 3.3 core...

Offline claude

  • 3f
  • ******
  • Posts: 1795
    • mathr.co.uk
Re: OpenGL Core Profile
« Reply #18 on: June 17, 2018, 09:15:33 PM »
Ok I'm not sure what the desired behaviour is, but
Code: [Select]
$ ./Fragmentarium-2.0.0 -g 3.0 -p none
"GL vers 3.0 requested."
"GL prof None requested."
"GL vers 4.5 used."
"GL prof Core used."
is not what I expected - What should I specifiy on the command line if I don't want a 4.5 core profile because the fragm engine and shaders don't support it yet and I want to make some fractals instead of hacking on the engine to make it work with 4.5 core?

Offline 3DickUlus

  • Administrator
  • *******
  • Posts: 2066
    • Digilantism
Re: OpenGL Core Profile
« Reply #19 on: June 17, 2018, 09:30:49 PM »
the desired behavior of the runtime-profile-version branch is entirely experimental to see if FragM can manage profile and version selection at runtime.

quotes from Qt docs...

The requested and the actual format may differ. Requesting a given OpenGL version does not mean the resulting context will target exactly the requested version. It is only guaranteed that the version/profile/options combination for the created context is compatible with the request, as long as the driver is able to provide such a context.

For example, requesting an OpenGL version 3.x core profile context may result in an OpenGL 4.x core profile context. Similarly, a request for OpenGL 2.1 may result in an OpenGL 3.0 context with deprecated functions enabled. Finally, depending on the driver, unsupported versions may result in either a context creation failure or in a context for the highest supported version.

It is possible to request a functions object for a different version and profile than that for which the context was created. To do this either use the template version of this function specifying the desired functions object type as the template parameter or by passing in a QOpenGLVersionProfile object as an argument to the non-template function.

Note that requests for function objects of other versions or profiles can fail and in doing so will return a null pointer. Situations in which creation of the functions object can fail are if the request cannot be satisfied due to asking for functions that are not in the version or profile of this context. For example:
Code: [Select]
QOpenGLFunctions_3_3_Core* funcs = 0;
  funcs = context->versionFunctions<QOpenGLFunctions_3_3_Core>();
  if (!funcs) {
      qWarning() << "Could not obtain required OpenGL context version";
Requesting a 3.3 core profile functions object would succeed.
Requesting a 3.3 compatibility profile functions object would fail. We would fail to resolve the deprecated functions.
Requesting a 4.3 core profile functions object would fail. We would fail to resolve the new core functions introduced in versions 4.0-4.3.
Requesting a 3.1 functions object would succeed. There is nothing in 3.1 that is not also in 3.3 core.

The way Qt implements GL is the reason I ended up with 2 versions of FragM, one for < GL4.1 and one for > GL4.0

I think profile and version selection at runtime will only be good for a limited range and definitely won't cover all possibilities.

edit: this leads me to believe that in order to cover all possibilities there would have to be 3 versions of FragM, Legacy, GLES and Modern (4+) eventually dropping the Legacy version.
« Last Edit: June 18, 2018, 12:51:37 AM by 3DickUlus »

OpenGL font rendering

Started by sjhalayka on Programming

2 Replies
Last post April 20, 2020, 05:00:47 PM
by sjhalayka
"Time Span"

Started by cricke49 on Fractal Image Gallery

0 Replies
Last post August 02, 2018, 07:05:21 AM
by cricke49
[Solved] Color interpolation

Started by galac on Programming

5 Replies
Last post March 02, 2019, 09:03:11 AM
by mclarekin
A new style of fractal imagery using fractal neural style transfer

Started by iRyanBell on Fractal Image Gallery

3 Replies
Last post October 03, 2020, 10:50:39 PM
by Jimw338
OpenGL version poll

Started by claude on Kalles Fraktaler

2 Replies
Last post February 19, 2021, 04:44:56 AM
by 3DickUlus