[osg-users] Specifying the GL context version to request

[Robert Osfield]

Hi Sandro,

On 21 August 2017 at 16:27, Sandro Mani <manisandro at gmail.com> wrote:

> Someone please correct me if I'm using the wrong terminology, but as far
> as I understand mesa (possibly restricted to the intel mesa drivers, but
> possibly also others such as ati and nouveau) only exposes GL3.2+
> functionality through the corresponding core profile. Compatibility profile
> is only implemented up to GL3.0 on my system:
>
>     Vendor: Intel Open Source Technology Center (0x8086)
>     Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)  (0x191b)
>     Version: 17.2.0
>     Accelerated: yes
>     Video memory: 3072MB
>     Unified memory: yes
>     Preferred profile: core (0x1)
>     Max core profile version: 4.5
>     Max compat profile version: 3.0
>     Max GLES1 profile version: 1.1
>     Max GLES[23] profile version: 3.2
>

What GL version is osgEarth now depending upon?


> Have you tried on an NVIdia or AMD system?
>
> No, but if I'm not mistaken they have a full(?) compatibility profile.
>

NVidia have been pretty reliable on maintaining compatibility, I can't
comment on AMD as I haven't used AMD for a number of years.

I don't have much time for chasing up all the various permutations of
hardwsare, drivers and OS's personally, but given the breadth of the OSG
community we generally can cover most things, even if it isn't right away.
When someone starts using a less common hardware/OS combination then we
have to rely upon them to give us feedback - exactly as you are doing right
now :-)


>
> FYI, I'm using NVidia under Kubunty 16.04 as my main build system and
> routinely mix latest GL features with just creating a normal graphics
> context,
>
>
>> Are the osgEarth team aware of the issues you've had?
>>
>> I once asked before investigating [1] but no-one reacted, I suppose they
>> are mostly using Windows. Now I have a better understanding of the
>> underlying issues (and indeed of what was missing in OSG itself), but
>> before reporting issues to the osgEarth team I'd like to understand what
>> the correct approach should be (if indeed they are doing something wrong).
>>
>
> My guess is that they probably haven't used Linix+Intel with the drivers
> that you are using so haven't come across the issue.  Real-time graphics
> under Linux has tended to mostly done with NVidia as Intel and AMD have had
> sub-standard GL drivers for looooong time.
>
> I suspect it's not really a case of the osgEarth team doing something
> wrong, but the Linux+Intel drivers adding a new constraint for keeping
> things working sweetly.
>
> I don't think it's adding a constraint, rather than the mesa developers
> focusing first on adding support for extensions required to expose the
> newest possible version in the core profile, and then working on the
> compatibility profile as time allows.
>

>From an end users perspectives lack of compatibility profile is a
constraint, if it weren't you wouldn't have had any problems.  From what
you describe it may well be a temporary constraint.



>
> I'm starting to wonder if you aren't hitting upon the same issues that
> Apple OSG users have had with Apple's decision to only support OpenGL 3+
> features on a graphics context without compatibility.  While it seems a
> uncontroversial decision at first glance it's ended up being a real pain
> for OpenGL users needing to maintain long lived applications that happen to
> rely upon both newer features when available as well as old fixed function
> pipeline features.  The Apple approach is fine for clean room application
> written recently such as new games but crap for the many companies that
> develop software that has a useful life that's over a decade long.
>
> It is likely that the issues are of similar nature yes. But since, with
> the changes from the PR + the proposed DisplaySettings change, I'm able to
> run osgEarth fine on this system, I'd say the situation is not that bad
> here, it's just a matter of clarifying how the profile version should be
> set.
>

Are you building the OSG with defaults?  Or are you building the OSG for
just GL3?

What viewer are using with osgEarth?  osgEarth itself is typically used as
NodeKit with end user application creating their own viewer and with it
graphics contexts.  This means even if osgEarth's own example programs
changed the way they create graphics context you'd end up with issues.

Have you tried running osgviewer with the osgEarth files?  osgviewer by
default uses the ViewAcrossAllScreens() configuration which will pass the
DisplaySettings::instance() when creating the graphics context.
osgviewer also has the command line parameters (run osgivewer --help):

 --gl-flags <mask> Set the hint of which GL flags projfile mask to use when
                    creating graphics contexts.
  --gl-profile-mask
<mask>
                    Set the hint of which GL context profile mask to use
when
                    creating graphics contexts.
  --gl-version
<major.minor>
                    Set the hint of which GL version to use when creating
                    graphics contexts.

You can also set the env vars (osgviewer --help-env):

  OSG_GL_CONTEXT_FLAGS
<uint>
                    Set the hint for the GL context flags to use when
creating
                    contexts.
  OSG_GL_CONTEXT_PROFILE_MASK
<uint>
                    Set the hint for the GL context profile mask to use when
                    creating contexts.
  OSG_GL_CONTEXT_VERSION
<major.minor>
                    Set the hint for the GL version to create contexts for.

Could you test these to see if it works with OSG master, without any of
your extra local modifications.  If they do work could you post the
settings you used.

Feedback on this might help guide what osgEarth example application might
be able to do better.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170821/12504d4a/attachment.htm>