[osg-users] Invalid operation on immutable texture

[OpenSceneGraph Users]

Hi,

I'm trying to find the origin of the two warnings we're getting in our application (OpenSceneGraph 3.6.4):
Warning: detected OpenGL error 'invalid operation' after applying attribute Viewport 0x5555576608a0
Warning: detected OpenGL error 'invalid operation' after applying GLMode 0xc11

If I'm using the OpenGL debug message extension then I can see a GL_INVALID_OPERATION
with the message 'Texture is immutable' caused by a call of glTexStorage2D in 'Texture2D.cpp'
in line 309. Both warnings are printed directly after this invalid operation.

I'm wondering how the texture object can ever be immutable here, because
it's just created in line 306.

Any ideas? Thanks!

Greetings,
Daniel
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[OpenSceneGraph Users]

> If I'm using the OpenGL debug message extension then I can see a GL_INVALID_OPERATION
> with the message 'Texture is immutable' caused by a call of glTexStorage2D in 'Texture2D.cpp'
> in line 309. Both warnings are printed directly after this invalid operation.
>
> I'm wondering how the texture object can ever be immutable here, because
> it's just created in line 306.

Looking at the implementation of 'TextureObjectSet::takeOrGenerate',
then a texture object from 'TextureObjectSet::_orphanedTextureObjects'
might be reused and then 'glTexStorage2D' might be called multiple times
on the same texture object, which would then result into GL_INVALID_OPERATION,
because 'glTexStorage2D' should be only called once and afterwards the
texture object is immutable in this regard.

Is this right?
Is there some kind of flag missing, if 'glTexStorage2D' has already been called?

[OpenSceneGraph Users]

On Tue, 24 Mar 2020 at 21:00, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:

> If I'm using the OpenGL debug message extension then I can see a GL_INVALID_OPERATION
> with the message 'Texture is immutable' caused by a call of glTexStorage2D in 'Texture2D.cpp'
> in line 309. Both warnings are printed directly after this invalid operation.
>
> I'm wondering how the texture object can ever be immutable here, because
> it's just created in line 306.

Looking at the implementation of 'TextureObjectSet::takeOrGenerate',
then a texture object from 'TextureObjectSet::_orphanedTextureObjects'
might be reused and then 'glTexStorage2D' might be called multiple times
on the same texture object, which would then result into GL_INVALID_OPERATION,
because 'glTexStorage2D' should be only called once and afterwards the
texture object is immutable in this regard.

Is this right?
Is there some kind of flag missing, if 'glTexStorage2D' has already been called?

This isn't something I considered when I merged the support for glTexStorage2D.  From your description it does sounds like reusing of the texture objects should be forbidden.  I haven't looked into the implementation side yet to look at problem so can't suggest a fix.

Could you create an example that reproduces the issue?  We can then use these as testbed for any fixes we come up with.

Cheers,

Robert.

 

 

[OpenSceneGraph Users]

Hi Robert,

> From your description it does sounds like reusing of the texture
> objects should be forbidden.

I think it might be fine to reuse the texture objects, because
'Texture::generateAndAssignTextureObject' takes all the parameters
needed by 'glTexStorage2D', so the returned texture object should
already have the right storage. What currently is missing, is a flag on
the texture object, if 'glTexStorage2D' has already been called for it.

> Could you create an example that reproduces the issue? We can then
> use these as testbed for any fixes we come up with.

I don't quite know how I should trigger this case in an example. I've
suspected that if a Texture2D gets deleted, then somehow its texture
object gets added to 'TextureObjectSet::_orphanedTextureObjects'. But
I can't find this in the code. I'm only seeing additions to
'_orphanedTextureObjects' in 'TextureObjectSet::deleteAllTextureObjects'
and 'TextureObjectSet::handlePendingOrphandedTextureObjects'.

[Chris Djali / AnyOldName3]

Hi Daniel,

It should be as simple as setting up a texture, using it to draw something, and then setting up a different texture to use instead. As long as the first one goes out of scope properly, it should end up in the orphaned pool, and then will eventually get reused. You might have to replace the texture multiple times before new ones get taken from the pool, though.

The following is probably more relevant for Robert:

This also seems to be the cause of an issue OpenMW's been tracking for a while: https://gitlab.com/OpenMW/openmw/issues/4773. We have stack traces and APITrace traces there if that helps. We'd got as far as identifying the commit responsible, but hadn't made the link between recycling things from the orphaned pool and immutable storage (although I know I'd looked at the orphaned pool already, so I guess it was before I'd done anything with immutable storage or I'd have made the connection). I've brought it up here in the past, but Robert didn't want to open an issue upstream until we were sure OpenMW wasn't doing anything dumb. I'm glad someone else has appeared who's done the hard part of tracking the problem down.

Cheers,

Chris

[julienvalentin51]

What i can think of that doesn't break whole design is to call glGetTexParameter (GL_TEXTURE_IMMUTABLE_FORMAT) before calling glTexStorage

[julienvalentin51]

I made a PR prefering a new bool in TextureObject to the glGetTexParameter solution. However, this solution breaks binary compatibility... if someone have a use case to tested it would worth to test if TewtureObject::allocated could be used instead