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+unsubscr...@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.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
