GL2 support

classic Classic list List threaded Threaded
11 messages Options
kostinio1 kostinio1
Reply | Threaded
Open this post in threaded view
|

GL2 support

I can't make osgEarth working on platforms where supported OpenGL compatibility profile is less then 3.3 (intel graphics mesa drivers for example). I tried to build OSG both with GL2 configuration and GL3. There only draws white sphere, without image layers. Is it supported or i do something wrong?
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

osgEarth requires OpenGL 3.3+. You will need to update your drivers.
Glenn Waldron / Pelican Mapping
kostinio1 kostinio1
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

I mean, is it necessary to have COMPAT profile? Can it work with 3.3CORE?
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

Yes, osgEarth 2.10 works well in GL CORE profile.

OSG must be built specifically to support GL CORE. Here's a guide:

https://gist.github.com/gwaldron/a56b0e77e7fa8587b698717d21f9366d
Glenn Waldron / Pelican Mapping
kostinio1 kostinio1
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

For example, i have next "osgearth_version.exe --caps" output:

[osgEarth]  [Capabilities] osgEarth Version: 2.10.0
[osgEarth]  [Capabilities] Detected hardware capabilities:
[osgEarth]  [Capabilities]   Vendor = VMware, Inc.
[osgEarth]  [Capabilities]   Renderer = llvmpipe (LLVM 6.0, 256 bits)
[osgEarth]  [Capabilities]   Version = 3.3 (Core Profile) Mesa 18.0.3 (git-ae12c5e990)
[osgEarth]  [Capabilities]   Core Profile = yes
[osgEarth]  [Capabilities]   Max GPU texture units = 32
[osgEarth]  [Capabilities]   Max GPU texture coord indices = 8
[osgEarth]  [Capabilities]   Max GPU attributes = 16
[osgEarth]  [Capabilities]   Max texture size = 8192
[osgEarth]  [Capabilities]   GLSL = yes
[osgEarth]  [Capabilities]   GLSL Version = 330
[osgEarth]  [Capabilities]   Texture arrays = yes
[osgEarth]  [Capabilities]   draw instanced = yes
[osgEarth]  [Capabilities]   Texture buffers = yes
[osgEarth]  [Capabilities]   Texture buffer max size = 65536
[osgEarth]  [Capabilities]   Compression = S3 RG

but image layers don't appear without any warnings.
plevy plevy
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

In reply to this post by kostinio1
It is not necessary to have compatibility, just 3.3 core and make sure OSG is built properly also.


On Fri, Nov 30, 2018 at 3:03 PM kostinio1 [via osgEarth] <[hidden email]> wrote:
I mean, is it necessary to have COMPAT profile? Can it work with 3.3CORE?


If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/GL2-support-tp7592207p7592210.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

In reply to this post by kostinio1
Kostinio,
You are using VMWare which is going to require some additional machinations. I know it can be done but it's out of my bailiwick so I will defer to others on the specifics.
Glenn Waldron / Pelican Mapping
emminizer emminizer
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

Hi Kostinio,

VMware uses the Mesa driver, and we've experienced some odd problems on Mesa drivers with GL3.

osgEarth::Capabilities (the code that generates that output you posted) instantiates its own context to gather the information.  That context should be created the same as the graphics context used to draw the earth.  But we found cases, especially on Mesa (VMware) and in Qt, where that didn't happen.

Your settings being requested when you create the context matter.  For example, we found that if multisample support is requested, even if GL 3.3 core profile is also requested, Mesa decided to return a context that was only GL2, in compatibility profile.  That meant shaders and other things didn't work.  We found that multisample was the culprit specifically because --caps was reporting a good GL3.3, but GL_VERSION calls on the actual context were different.  We traced it to requests for sample buffers.


Another issue we had was that on Linux VMs with Mesa, including VMware ones, we had to explicitly set the MESA_GL_VERSION_OVERRIDE environment variable, or our requested GL version was ignored.  I think you don't have this problem because I think it manifested itself in Capabilities too, only ever giving 2.x contexts.

Without more information on the actual errors and details on the context that is actually being used to render osgEarth, I can't help much more.  Hope this helps.

 - Dan
remoe remoe
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

Dan, very interesting. Thanks for this.
Remo Eichenberger, Switzerland
kostinio1 kostinio1
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

This post was updated on .
In reply to this post by emminizer
Hi Dan,
Thank you for detailed answer. I check GL_VERSION by calling glGetString(GL_VERSION) between calling frame() on my osgViewer::Viewer. It's also required to call makeCurrent() on osg::Graphic context which i get from viewer's camera. It should be actual context. I get "3.3 (Core Profile) Mesa 18.0.3 (git-ae12c5e990)" version string.
I tried to create context in 2 ways:
If I don't set anything Viewer creates x11 window with white sphere which should be Earth, and 3.3 (Core Profile) version string is reported by opengl.
If I'm using osgQt library, by default version is 3.0 and there is no graphics at all. If I put MESA_GL_VERSION_OVERRIDE 3.3(CORE or without it), version becomes 3.3 (still without core profile) and white sphere appears. Finally I need to set QGLFormat on underlying QGLWidget to 3.3 version and after this opengl reports 3.3(Core), but it's still white sphere on a screen. That looks like OSG trying to work in compatibility profile which don't exist.
I get 2 warnings when close window:
void StateSet::setGlobalDefaults() ShaderPipeline disabled.
Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..)
I tried to enable ShaderPipeline in osg::DisplaySettings::Instance() and after this message becomes
void StateSet::setGlobalDefaults() ShaderPipeline enabled, numTextUnits = 4
, but still no effect. (actually i don't know what this option do but it's disabled on my another working GL2 configuration)

I also tried to disable multisampling wherever it's possible (DisplaySettings, window traits, QGLFormat), but looks like it was already set to 0.
emminizer emminizer
Reply | Threaded
Open this post in threaded view
|

Re: GL2 support

Hi Kostinio,

Sounds like you were getting past the mesa issues I originally had.  Yes, you'll have to set the QGLFormat appropriately; I struggled a bit with osgQt to get it working.

The OSG_GL_ERROR_CHECKING environment variable might be useful to you.  Try setting it to 1 and rerunning.  Does it give you more details on the invalid operation?

You can also run with MESA_DEBUG=1 environment variable.  I almost forgot about that one.  Of all the problems I had with getting Mesa running, this environment variable sort of made up for it.  It on a driver level gave a much more verbose output on what was going on with the fault you're seeing.

The ShaderPipeline error has been reported a while back on the OSG forums, and only impacts versions newer than what I'm using for OSG.  I'm currently on 3.6.3.  I don't know that it impacts you other than as a debug message.  But it is certainly possible there's some bug in the master (or its interaction with osgEarth) that is causing this behavior.

 - Dan