<div dir="ltr"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I can't investigate either issue without being able to recreate the crash/GL errors myself. If either of these issues occur on an existing OSG example then I can take it from there.</blockquote><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Short of being able to recreate the issue and investigate it myself the only thing I can do is suggest ways of investigating the issue that might reveal the cause of the issues.</blockquote><div><br></div><div>Your suggestions are the kinds of thing I'd be looking at if I had more time, but unfortunately, I don't. However, it might actually be reasonable for you to take a look yourself. I'd put money on OpenMW being the most widely-installed OSG application, and it's open-source, so it would be a good candidate for part of your own regression testing.</div><div><br></div><div>Sorry to just pile on work when I'm unable to help myself. We just don't have anyone who's both got time and familiarity with OSG.</div><div><br></div><div>Thanks,</div><div><br></div><div>Chris</div><br>On Wednesday, 18 December 2019 10:56:39 UTC, Robert Osfield wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><br><br>On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Robert,<div><br></div><div>OpenMW still experiences some regressions when built with OSG 3.6.x instead of 3.4.1. It's completely possible they're because we're trying to coerce OSG systems to do things they weren't intended to as it's a big project created without much interaction with the OSG community.</div><div><br></div><div>The two issues we're tracking are:</div><div><ul><li><a href="https://gitlab.com/OpenMW/openmw/issues/5205" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FOpenMW%2Fopenmw%2Fissues%2F5205\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGM0fNG5XzEsuX9eYwh6Dmjzmmn4w';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FOpenMW%2Fopenmw%2Fissues%2F5205\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGM0fNG5XzEsuX9eYwh6Dmjzmmn4w';return true;">https://gitlab.com/OpenMW/<wbr>openmw/issues/5205</a> the builds provided by Arch Linux crash. The Arch packagers think they're not doing anything abnormally, so I don't have a clue where the issue actually lies.<br></li></ul></div></div></blockquote><div>My best guess is there is some threading issue where a slightly different build resulting slightly different data alignment in a race condition becoming critical. That's just a guess though, there isn't any evidence in the thread above that can pin point any specific problem. <br></div><div><br></div><div>Given the fickle nature of threading problems, just
because it occurs in 3.6.x but not 3.4.x doesn't mean that there has
been a bug introduced after 3.4, it just needs some condition to
slightly change that cause some of the data in the application to be
aligned different and over the application goes.</div><div><br></div><div>The best I can recommend is to run the application with valgrind --tool=helgrind to see if it picks up any race conditions.</div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><li></li><li><a href="https://gitlab.com/OpenMW/openmw/issues/4773" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FOpenMW%2Fopenmw%2Fissues%2F4773\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH741bLS8XtrWKzU4KMeAiigHTLjg';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FOpenMW%2Fopenmw%2Fissues%2F4773\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH741bLS8XtrWKzU4KMeAiigHTLjg';return true;">https://gitlab.com/OpenMW/<wbr>openmw/issues/4773</a> OpenGL errors we didn't use to get. This hasn't been very thoroughly investigated at all.<br></li></ul><div>There are potentially other issues, too. I had a collection of stack traces of crashes and OpenGL errors that I was working through, and not all of them ended up on our tracker. As the issues I'd already brought up on the forums were taking a while to flush through due to your focus on VSG, tracking down OSG regressions had been put on the back burner, and I don't have a huge amount of time right now. That means the best I can do if you want things narrowing down is to try and get people to replicate the issues with the tip of the 3.6 branch and potentially get stack traces.</div><div><br></div></div></div></blockquote><div><br></div><div>Does this happen with all hardware/OS/driver combinations or just particular ones?<br></div><div><br></div><div>From the glTextStorage2D documentation at <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL-Refpages%2Fgl4%2Fhtml%2FglTexStorage2D.xhtml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEcUCDScP-dhEpDN9aZrPf61QucBQ';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL-Refpages%2Fgl4%2Fhtml%2FglTexStorage2D.xhtml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEcUCDScP-dhEpDN9aZrPf61QucBQ';return true;">https://www.khronos.org/<wbr>registry/OpenGL-Refpages/gl4/<wbr>html/glTexStorage2D.xhtml</a><br></div><div><br></div><div><div style="margin-left:40px">Errors<br><br>GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to target.<br><br>GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not the name of an existing texture object.<br><br>GL_INVALID_ENUM is generated if internalformat is not a valid sized internal format.<br><br>GL_INVALID_ENUM is generated if target or the effective target of texture is not one of the accepted targets described above.<br><br>GL_INVALID_VALUE is generated if width, height or levels are less than 1.<br><br>GL_INVALID_OPERATION is generated if target is GL_TEXTURE_1D_ARRAY or GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(width)⌋+1<br><br>GL_INVALID_OPERATION is generated if target is not GL_TEXTURE_1D_ARRAY or GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(max(width, height))⌋+1<br></div></div><div><br></div><div>Given the <code><span lang="plaintext">glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid on it's own we are left with:</span></code></div><div><br><div style="margin-left:40px"><code><span lang="plaintext">GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to target.</span></code></div><div style="margin-left:40px"><br><code><span lang="plaintext"></span></code></div><code><span lang="plaintext"></span></code><code></code><code><span lang="plaintext">The next step would be to put into some test code that Texture2D.cpp to track what is happening right before the call. There is a textureObject->bind() before each call to glTexStorage2D, but perhaps this is failing for some reason.</span></code></div><div><code><span lang="plaintext"><br></span></code></div><div><code><span lang="plaintext"></span></code> GLenum texStorageSizedInternalFormat = extensions-><wbr>isTextureStorageEnabled && (_borderWidth==0) ? selectSizedInternalFormat() : 0;<br> if (<wbr>texStorageSizedInternalFormat!<wbr>=0)<br> {<br> textureObject = generateAndAssignTextureObject<wbr>(contextID, GL_TEXTURE_2D, _numMipmapLevels, texStorageSizedInternalFormat, _textureWidth, _textureHeight, 1, _borderWidth);<br> textureObject->bind();<br> applyTexParameters(GL_TEXTURE_<wbr>2D, state);<br> extensions->glTexStorage2D( GL_TEXTURE_2D, osg::maximum(_numMipmapLevels,<wbr>1), texStorageSizedInternalFormat,<br> _textureWidth, _textureHeight);<br> }<br> else<br> {<br> GLenum internalFormat = _sourceFormat ? _sourceFormat : _internalFormat;<br> textureObject = generateAndAssignTextureObject<wbr>(contextID, GL_TEXTURE_2D, _numMipmapLevels, internalFormat, _textureWidth, _textureHeight, 1, _borderWidth);<br> textureObject->bind();<br> applyTexParameters(GL_TEXTURE_<wbr>2D, state);<br> glTexImage2D( GL_TEXTURE_2D, 0, _internalFormat,<br> _textureWidth, _textureHeight, _borderWidth,<br> internalFormat,<br> _sourceType ? _sourceType : GL_UNSIGNED_BYTE,<br> 0);<br> }<br></div><div><br></div><div>I can't investigate either issue without being able to recreate the crash/GL errors myself. If either of these issues occur on an existing OSG example then I can take it from there.</div><div><br></div><div>Short of being able to recreate the issue and investigate it myself the only thing I can do is suggest ways of investigating the issue that might reveal the cause of the issues.</div><div><br></div><div>Cheers,<br></div><div>Robert<code>.</code><br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:osg-users+unsubscribe@googlegroups.com">osg-users+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/osg-users/160be727-08c3-499b-9a43-c521130c2941%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/osg-users/160be727-08c3-499b-9a43-c521130c2941%40googlegroups.com</a>.<br />