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

[Sandro Mani]

Hi Robert


On 21.08.2017 19:06, Robert Osfield wrote:
> 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_PROFILEif 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
>
Ok I'll fire off a build without passing any cmake options and check 
what happens when I just set the environment variables.
>
>     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.
Sure. However I'm curious, how is the logic supposed to work under 
Windows, where support for specifying the GL version was already 
implemented? Wouldn't you hit the same issues on that platform also?
>
> 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.
Not that I want to be annoying or repetitive, but surely it's not ideal 
that osgEarth::Capabilities::Capabilities performs it's checks with a 
1.0 context, even though you specify OSG_GL_CONTEXT_VERSION=4.0? Or am I 
missing something here?

Best
Sandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170821/09b1f2d1/attachment-0001.htm>