[osg-users] Re: Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
>
> 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.
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.
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.
Thanks,
Chris
On Wednesday, 18 December 2019 10:56:39 UTC, Robert Osfield wrote:
>
>
>
> 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,
[osg-users] Re: Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
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
[osg-users] Re: Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
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. - 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. Sorry I can't be more specific, Chris On Monday, 16 December 2019 17:16:01 UTC, Robert Osfield wrote: > > Hi All, > > I have merged the outstanding pull requests and made a couple of bug fixes > that are now checked into the OpenSceneGraph-3.6 branch: > > > https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6 > > Could everyone test out this branch to see how well it's working on your > build platforms and against your hardware/OS/application combinations. If > everything looks solid I make a 3.6.5 release candidate with the aim to > make a 3.6.5 in January. > > Thanks in advance with your help in testing. > Robert. > > *-- ChangeLog since the 3.6.4 release on 26th of July 2019:* > > Mon, 16 Dec 2019 16:51:16 + > Author : Robert Osfield > Added automatically removal from the OjbectCache when a object or it's > subgraph contain Texture that no longer have an osg::Image. > > Mon, 16 Dec 2019 11:54:12 + > Author : OpenSceneGraph git repository > Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug compile > error for ReaderWriterTGA > > Mon, 16 Dec 2019 11:02:41 +0100 > Author : Laurens Voerman > fix debug compile error for ReaderWriterTGA > > Mon, 16 Dec 2019 09:40:30 + > Author : OpenSceneGraph git repository > Merge pull request #870 from > eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and > isVAOSupported flags fixed > > Mon, 16 Dec 2019 09:40:00 + > Author : OpenSceneGraph git repository > Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded FBO > GL extensions (useful for mobile VR etc.) > > Fri, 13 Dec 2019 19:40:11 +0300 > Author : konstantin.matveyev > GLExtensions's isPBOSupported and isVAOSupported flags fixed for > GLES2+GLES3 configuration > > Fri, 13 Dec 2019 19:42:30 +0300 > Author : konstantin.matveyev > GLExtensions's isInvalidateFramebufferSupported flag improved > > Tue, 26 Nov 2019 17:17:38 +0800 > Author : PntAndCnt > Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES > cause osg3::osgText target looking for > openscegraph-Fontconfig-import-targets.cmake, which doesn't exists. > > > Sun, 13 Oct 2019 20:24:36 +0800 > Author : PntAndCnt > Fix a typo and invisible 3dtext in examples/osgtext.Second text alignment > is wrong when "--alignment" specified. > > 3D text radius is too small, only SCREEN_COORDS can be seen. > > Text position should multiply radius. > > > Tue, 3 Sep 2019 16:11:14 +0800 > Author : Kent > Mered fix for internalFormat > > Thu, 12 Dec 2019 18:41:23 +0300 > Author : valid-ptr > glInvalidateFramebuffer added to GLExtensions > > Thu, 31 Oct 2019 18:59:04 +0300 > Author : konstantin.matveyev > glFramebufferTexture2DMultisample added to GLExtensions > > Tue, 10 Dec 2019 15:08:25 +0300 > Author : Dmitry Marakasov > Add FreeBSD-specific code bits for pthread_setaffinity_np support > > Thu, 12 Dec 2019 13:25:44 + > Author : Robert Osfield > Fix linking with Xinerama > > Thu, 12 Dec 2019 13:09:33 + > Author : OpenSceneGraph git repository > Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the > default plugin for video files. > > Fri, 22 Nov 2019 21:07:36 +0100 > Author : elsid > Fix clang 8 & libc++ build errorsReplace operators for implicit type > conversion by explicit data() method to > access implementation pointer and subscript operator to access element by > index just like in std::vector. > > src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (colormap == NULL) > ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16:
