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

Sandro Mani manisandro at gmail.com
Mon Aug 21 08:27:11 PDT 2017


Hi Robert

On 21.08.2017 17:08, Robert Osfield wrote:
> Hi Sandro,
>
> On 21 August 2017 at 15:21, Sandro Mani <manisandro at gmail.com 
> <mailto:manisandro at gmail.com>> wrote:
>
>     OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake
>     GT2)
>     OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.0-rc4
>     OpenGL core profile shading language version string: 4.50
>
>
> Is there a reason why the driver isn't just directly supporting the GL 
> features that osgEarth is using?  Is the Intel/Mesa driver limiting 
> features in some way?
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


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

Sandro

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


More information about the osg-users mailing list