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

[Robert Osfield]

HI Sandro,

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

> Agreed, I didn't put much though into it, I just checked that I hit the
> OSG_GL3_FEATURES when doing the work on the context.
>

The OSG is able to detect and use features at runtime, you don't actually
need to explictly set OSG_GL3_FEATURES.  It's only when you start use a
core profile do you need to be selective about the OSG_GL3_FEATURES, but
these settings will be set appropriate if you choose OPENGL_PROFILE to be
GL3 or GLCORE.


> Things should work with just:
>
> cmake .
> make -j 4   # 4 is number of cores available
>
> When you using the OPENGL_PROFILE it'll set the OSG_*_AVAILABLE options
> for you, but in general build with defaults unless you specifically need a
> particular feature set.
>
> Well, in this case I needed it though, right? I mean, OPENGL_PROFILE
> defaults to "GL2".
>

You should only need to OPENGL_PROFILE something other than defaults if you
specifically want just a non compatible graphics context.  It sounds like
the Intel driver might require OPENGL_PROFILE if you want to enable the
latest GL features, something you won't need under NVIidia and possible
AMD. Try using the OSG_GL_CONTEXT_VERSION and OSG_GL_CONTEXT_PROFILE_MASK
env vars instead of the above DisplaySettings::instance() code i,e,

export OSG_GL_CONTEXT_VERSION=4.0
> export OSG_GL_CONTEXT_PROFILE_MASK=1
>
> Yes as mentioned this also works. But the open issue for me still remains
> the first context created by osgEarth::Capabilities::
> Capabilities (see first of the stack traces I posted above). In my view
> either this is a bug in osgEarth that it creates the traits without
> honouring the desired GL version, or OSG should otherwise ensure the traits
> contain the overridden GL version.
>

I don't think it's appropriate to classify a bug for something that is
retrospectively using the software with drivers that add their own
constraints.  The OSG hasn't ever worked the way you want it to work - I've
only just integrated the changes to the OSG to support passing the GL
versions for GLX, so only now can we start talking about passing on
suggestions of how to utilize it to the osgEath team.

I see it as a constraint on osgEarth working with Intel drivers and recent
GL versions and associate drivers.  What we are talking about is working
around these constraints in the driver to provide to full osgEarth
functionality across a wider range of hardware.  The first step has been to
add the GL version functionality to OSG's GLX support.

Whether we need to push any changes to osgEarth is something I'm not clear
on, if the above export's now work with OSG master and osgEarth then I
think we are most of the way to getting what is reasonable to expect.

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