[osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release

[Robert Osfield]

On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote:
>
> Hi Robert,
>
> 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.
>
> The two issues we're tracking are:
>
>    - https://gitlab.com/OpenMW/openmw/issues/5205 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.
>    
> 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.  

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.

The best I can recommend is to run the application with valgrind 
--tool=helgrind to see if it picks up any race conditions.

>
>    - 
>    - https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we didn't 
>    use to get. This hasn't been very thoroughly investigated at all.
>    
> 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.
>
>
Does this happen with all hardware/OS/driver combinations or just 
particular ones?

>From the glTextStorage2D documentation at 
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml

Errors

GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to 
target.

GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not 
the name of an existing texture object.

GL_INVALID_ENUM is generated if internalformat is not a valid sized 
internal format.

GL_INVALID_ENUM is generated if target or the effective target of texture 
is not one of the accepted targets described above.

GL_INVALID_VALUE is generated if width, height or levels are less than 1.

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

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

Given the glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid 
on it's own we are left with:

GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to 
target.

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.

        GLenum texStorageSizedInternalFormat = 
extensions->isTextureStorageEnabled && (_borderWidth==0) ? 
selectSizedInternalFormat() : 0;
         if (texStorageSizedInternalFormat!=0)
         {
             textureObject = generateAndAssignTextureObject(contextID, 
GL_TEXTURE_2D, _numMipmapLevels, texStorageSizedInternalFormat, 
_textureWidth, _textureHeight, 1, _borderWidth);
             textureObject->bind();
             applyTexParameters(GL_TEXTURE_2D, state);
             extensions->glTexStorage2D( GL_TEXTURE_2D, 
osg::maximum(_numMipmapLevels,1), texStorageSizedInternalFormat,
                      _textureWidth, _textureHeight);
         }
         else
         {
             GLenum internalFormat = _sourceFormat ? _sourceFormat : 
_internalFormat;
             textureObject = generateAndAssignTextureObject(contextID, 
GL_TEXTURE_2D, _numMipmapLevels, internalFormat, _textureWidth, 
_textureHeight, 1, _borderWidth);
             textureObject->bind();
             applyTexParameters(GL_TEXTURE_2D, state);
             glTexImage2D( GL_TEXTURE_2D, 0, _internalFormat,
                      _textureWidth, _textureHeight, _borderWidth,
                      internalFormat,
                      _sourceType ? _sourceType : GL_UNSIGNED_BYTE,
                      0);
        }

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.

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.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/87305a40-3323-467a-a446-ef0e602d1e74%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20191218/643e1db0/attachment.html>