[osg3.6] prevent immutability setting when textureobject is taken from orphans

[mp3butcher]

a quick fix for #935 a minor problem that affect master too

[AnyOldName3]

I just got around to actually testing this, and it does indeed fix the issue in OpenMW, as anticipated. I imagine there'll be some tweaking before this is actually merged (setted isn't a word, for example), but something based on this should be good.

[openscenegraph]

I have started looking at the PR and the underlying code. Use of _immutableSetted variable is rather awkward in terms of language. We'll need a more appropriate name if this variable is required.

Looking at Texture::TextureObject there is already an _allocated member variable which sounds like there is functionality overlap with _immutableSetted. The code path contain the glTextureStorage2D does set the Allocated parameters which is possibly a bit odd. The underlying code goes many years back before glTextureStoage2D code was introduced, it might be was these new features were introduced not everything has been evolved correctly w.r.t working with the old features as well as the new.

I'm coming to the topic a bit cold so don't have any fully formed opinions yet. One of my first thoughts are to explore whether the TextureObject::_allocated/setAllocated() functionality is something we can use to decided whether the glTextureStorage2D should be called or not. If so then a check against if (texturObject-isAllocated()) would be appropriate along with correct calling of setAllocated().

Thoughts?

[AnyOldName3]

I think texture allocation versus immutable allocation are different concerns, even if they're related, so even if they can be combined, it'll potentially be misleading. glTexImage allocates a texture, but not immutably, so it can be reallocated again later.

[openscenegraph]

On Wed, 29 Apr 2020 at 19:00, Chris Djali ***@***.***> wrote: I think texture allocation versus immutable allocation are different concerns, even if they're related, so even if they *can* be combined, it'll potentially be misleading. glTexImage allocates a texture, but not immutably, so it can be reallocated again later.

The principle behind the OSG's cache of old texture objects is that they can be reused without reallocation, so once they are created they shouldn't change size. So the immutable aspect should be OK. However, I can't say for sure without reviewing all the usage of TextureObject. My hunch is that proper use of the allocated flag and sizing of TextureObject members should be sufficient.

[mp3butcher]

My hunch is that proper use of the allocated flag and sizing of
TextureObject members should be sufficient.

_allocated could serve the propose if we remove _allocated=true from TextureObject::setAllocated and set it true out of TextureObject scope (in TextureXXX::apply)
@robertosfield Is it what you want?
M guess is packing allocated and immutabilitySet in a bitfield or refactoring (gloup) to take into account immutability are more sensible

[robertosfield]

@mp3butcher sometimes you perplex me:

"_allocated could serve the propose if we remove _allocated=true from TextureObject::setAllocated"

I can't think why you'd ever want to change a feature behavior so it doesn't behave in the most obvious way and in the way it was designed for. setAllocated should set _allocated = true, because it's the most logically sound thing to do with this naming of methods.

All I'm asking here is whether the problem code block in question, the on with the glTexStorage2D call is missing a check if (textureObject->isAllocated()) and missing a corresponding setAllocated().

A little above the problem section we have a code block:

       if (textureObject->isAllocated() && image->supportsTextureSubloading())
        {
            //OSG_NOTICE<<"Reusing texture object"<<std::endl;
            applyTexImage2D_subload(state,GL_TEXTURE_2D,image.get(),
                                 _textureWidth, _textureHeight, _internalFormat, _numMipmapLevels);
        }
        else
        {
            //OSG_NOTICE<<"Creating new texture object"<<std::endl;
            applyTexImage2D_load(state,GL_TEXTURE_2D,image.get(),
                                 _textureWidth, _textureHeight, _numMipmapLevels);

            textureObject->setAllocated(true);
        }

Could it simply be that the glTexStorage2D code path is missing that this type of usage? FYI, I'm not the original author of the glTexStorage2D so it might be that the original contributor of it didn't realize about the Allocated support in TextureObject and I didn't spot the problem when merging.

I don't have a test case to run and see the problem happening so I'm working a bit blind on this particular bug report.

[mp3butcher]

tested and ok for merging

[robertosfield]

@mp3butcher Changes look good :-)

[robertosfield]

I now have merged the changes into master.

…

On Sun, 3 May 2020 at 09:37, OpenSceneGraph git repository < ***@***.***> wrote: Merged #934 <#934> into OpenSceneGraph-3.6. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#934 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUESMX6Q2Q3QBVOXOA3RPUUOJANCNFSM4LTZEC7A> .

[AnyOldName3]

I think there's potentially a race condition where this can still happen. I've got an APITrace (unfortunately 16 GB long because it reproduces really rarely when APITrace is attached) where glTexStorage2D gets called on a texture it's already been called on, despite using an OSG build featuring this PR's changes. These are the interesting calls:

242310476 @1 glGenTextures(n = 1, textures = [228])
242310477 @1 glBindTexture(target = GL_TEXTURE_2D, texture = 228)
255218421 @1 glDeleteTextures(n = 1, textures = [228])
255689975 @1 glGenTextures(n = 1, textures = [228])
255689976 @1 glBindTexture(target = GL_TEXTURE_2D, texture = 228)
255689986 @1 glTexStorage2D(target = GL_TEXTURE_2D, levels = 1, internalformat = GL_RGB8, width = 512, height = 512)
255689996 @1 wglSwapBuffers(hdc = 0xffffffffed010d73) = TRUE
255690042 @1 glFramebufferTexture2D(target = GL_DRAW_FRAMEBUFFER, attachment = GL_COLOR_ATTACHMENT0, textarget = GL_TEXTURE_2D, texture = 228, level = 0)
269792082 @1 glBindTexture(target = GL_TEXTURE_2D, texture = 228)
269792092 @1 glTexStorage2D(target = GL_TEXTURE_2D, levels = 1, internalformat = GL_RGB8, width = 512, height = 512)
269792095 @1 glFramebufferTexture2D(target = GL_DRAW_FRAMEBUFFER, attachment = GL_COLOR_ATTACHMENT0, textarget = GL_TEXTURE_2D, texture = 228, level = 0)

I think what's happening is possibly an incremental compile operation getting split across two frames, but I'm not entirely sure how _allocated could end up unset because of that.

[AnyOldName3]

It's harder to reproduce with a build made from a more recent commit, though, so either some changes have hidden it, or it's been fixed.