<div dir="ltr">Hi Sandro,<br><div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2017 at 16:27, Sandro Mani <span dir="ltr"><<a href="mailto:manisandro@gmail.com" target="_blank">manisandro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">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:<br>
<br>
Vendor: Intel Open Source Technology Center (0x8086)<br>
Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
(0x191b)<br>
Version: 17.2.0<br>
Accelerated: yes<br>
Video memory: 3072MB<br>
Unified memory: yes<br>
Preferred profile: core (0x1)<br>
Max core profile version: 4.5<br>
Max compat profile version: 3.0<br>
Max GLES1 profile version: 1.1<br>
Max GLES[23] profile version: 3.2<span class="gmail-"><br></span></div></blockquote><div><br></div><div>What GL version is osgEarth now depending upon?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"></span><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Have you tried on an NVIdia or AMD system?<br>
</div>
</div>
</div>
</div>
</blockquote></span>
No, but if I'm not mistaken they have a full(?) compatibility
profile.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>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.<br><br></div><div>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 :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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, <br>
</div>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-m_2984855750201117585gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Are the osgEarth team
aware of the issues you've had?<br>
<br>
</div>
</div>
</blockquote>
</span> 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).<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote></span>
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.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>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.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
<div>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.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote></span>
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.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br></div><div>Are you building the OSG with defaults? Or are you building the OSG for just GL3?<br><br></div><div>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.<br><br></div><div>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):<br><br> --gl-flags <mask> Set the hint of which GL flags projfile mask to use when<br> creating graphics contexts.<br> --gl-profile-mask <mask> <br> Set the hint of which GL context profile mask to use when<br> creating graphics contexts.<br> --gl-version <major.minor> <br> Set the hint of which GL version to use when creating<br> graphics contexts.<br><br></div><div>You can also set the env vars (osgviewer --help-env):<br><br> OSG_GL_CONTEXT_FLAGS <uint> <br> Set the hint for the GL context flags to use when creating<br> contexts.<br> OSG_GL_CONTEXT_PROFILE_MASK <uint> <br> Set the hint for the GL context profile mask to use when<br> creating contexts.<br> OSG_GL_CONTEXT_VERSION <major.minor> <br> Set the hint for the GL version to create contexts for.<br></div><div><br></div><div>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.<br><br></div><div>Feedback on this might help guide what osgEarth example application might be able to do better.<br></div><div><br></div><div>Robert.<br></div></div></div></div>