Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Bradley Anderegg]

Hi,

I can confirm I am seeing this on Windows 7 x64, in addition, I am also seeing 
an occasional driver crash.

Typically after running for about 4 or 5 hours, the video driver will shutdown 
and the OS pops up a notification that says it is has been restarted.  The OS 
recovers but the application crashes on the call to 
releaseContextImplementation() line 2081 in GraphicsWindowWin32.cpp.

I'm not yet sure if these are related.


Thank you!

Cheers,
Bradley

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65390#65390





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Trajce Nikolov NICK]

Scott, your fixes did not fix the issues on the OSX with the DDS textures
... But thanks anyway

On Thu, Sep 24, 2015 at 9:26 PM, Robert Osfield 
wrote:

> Hi Scott,
>
> Thanks for the follow up.
>
> Could you post the whole modified file, this way we can avoid any possible
> copy and past errors.
>
> Thanks,
> Robert.
>
> On 24 September 2015 at 20:13, Davis, Timothy S CTR comnavairsyscom <
> timothy.s.davis@navy.mil> wrote:
>
>> Sorry.  It keeps trying to encrypt the message.
>>
>> Robert
>>
>> While continuing to build a model that results in the problem, I
>> discovered something I didn't see before.  The IVE model had an incorrect
>> number of mipmap levels (it had 8) for a 32x32 texture.  It makes sense
>> that glTexStorage2D would generate INVALID_OPERATION in this case.
>> Rebuilding the model from a source with uncompressed textures and
>> recompressing the textures worked.  The original model was converted with a
>> much older version of OSG, pre OSG 3 for sure.
>>
>> So I was barking up the wrong tree:)
>>
>> That addresses my specific issue without needing a change to OSG 3.4.0.
>> However, I still think it is worth trying for the OSX case.
>>
>>
>> Trajce
>>
>> In osg/Texture.cpp, function applyTexImage2D(), find the line:
>>
>> useTexStorage &= sizedInternalFormat != 0;
>>
>> add the following after the line:
>>
>> if ( useTexStorage && compressed_image && numMipmapLevels > 2 )
>> {
>> numMipmapLevels -= 2;
>> }
>>
>> This is clearly not production quality as it assumes block size is 4 and
>> complete mipmaps to 1x1.  It should be enough to check the approach.  You
>> may have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is
>> incomplete, but I didn't have that issue.
>>
>> Scott
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.

[Robert Osfield]

Hi Scott,

The problem under OSX looks to be a driver bug, there is small chance that
it's related to the problems you are seeing but likely a different issue.

The problem you describe sounds like a driver bug too, testing out without
other drivers/hardware/OS combinations would help with this.  Have you
tried any other combinations?

There is possibility that different drivers handle the input data in
different ways.  The addition of the glTextureStorage2D usage might be
adding another code pathway in the drivers that adds/removes/changes the
way that data is handled introducing the inconsistency that you are seeing.
The driver shouldn't be doing this, but no code is perfect.

Without an example model that can reproduce the problem there isn't much
others can do at this stage.  Potentially we could add a catch for
compressed textures + mipmap levels into osg::Texture*, but before any mods
to the core OSG I'd need to have a test example to work from that exhibits
a problem so that can confirm that these changes actually work.

Robert.

On 23 September 2015 at 22:24, Davis, Timothy S CTR comnavairsyscom <
timothy.s.davis@navy.mil> wrote:

> Robert
>
> Sorry for the bad posting of my last message.  I'll repeat here and update
> with new information.
>
> The code in question was added sometime during OSG 3.3.x development.  It
> was not in OSG 3.2.1.  I just recently jumped from 3.2.1 to 3.4.0 for my
> application which is when I ran into the problem.  It worked fine with OSG
> 3.2.1.  In particular, it appears to be the added support for texture
> storage objects and not specifically "compressed texture support".  I noted
> the call that gave the error was glCompressTexSubImage2D.  However I should
> point out that I determined this using gDEBugger.  My version doesn't seem
> to understand the texture storage extension.  So the error may have been
> generated by the earlier call to setup the texture storage.  I checked into
> this and indeed an INVALID_OPERATION was generated by the call to
> glTexStorage2D.
>
> In addition, on my machine the problem doesn't affect all compressed
> textures with mipmaps.  The model that first caused the problem had several
> such textures, but only a small 32x32 texture resulted in a problem.  I
> have no idea why this would be the case.  However I remember others
> reporting issues with loading DDS textures and working around it by
> commenting out the following line in ReaderWriterDDS:
> If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets);
> Commenting that line out would appear to disable mipmaps for compressed
> textures and avoid the problems I've indicated.  This older problem was
> reported only on OSX, but may be related.  This type of changed made to the
> IVE loader would also have fixed my problem at the expense of disabling
> mipmaps.
>
> Looking at a different model, the one problem texture was 128x128.  So
> there appears to be nothing special about the size.  I did see that the
> rendering result for the models that have the problem is different between
> using the fixed-function pipeline and a shader.  With the FFP, the
> rendering appears correct, though the INVALID_OPERATION error is
> generated.  With a shader, the textures rendered black.
>
> I looked at making a simple model that would reproduce the problem.
> However, I've failed to create such a model.  It just always works with no
> render problems or OpenGL errors.
>
> For my application, I've worked around the problem by reducing the number
> of mipmap levels to avoid using levels smaller than the compression block
> size.  So I consider the problem fixed for me.  However, I feel this is
> information that you and the rest of the community can use.
>
>
> Scott
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Trajce Nikolov NICK]

Hi Scott,

I am experiencing this issue on OSX .. Can you submit a patch/fix to test
it against the problematic models I have?

Thanks a bunch!

Nick

On Thu, Sep 24, 2015 at 4:18 PM, Davis, Timothy S CTR comnavairsyscom <
timothy.s.davis@navy.mil> wrote:

> Robert
>
> I'd agree that I'm dealing with a driver bug.  I'm just not sure what the
> bug is.  I think we are working in a underspecified area of OpenGL when
> dealing with mipmap levels smaller than the compression block size.
> However, I know that my driver generates 2x2 and 1x1 mipmaps for hardware
> generated compressed textures and this would suggest that it should happily
> work with these levels.
>
> I don't agree that it is unrelated to the OSX driver issue.  Certainly the
> drivers are different and the symptoms may be different.  But they both
> appear to touch the same question; what happens with mipmaps smaller than
> the block size.  I don't have access to an OSX machine however, so I cannot
> investigate this claim further.
>
> I have not tried different driver/hardware/OS combinations.  I'd agree
> that this would be useful, but I'm somewhat limited in how far I can go
> with this.
>
> I'd agree that a change to the core OSG is not warranted at this time.
> The models that cause the problem are not distributable.  I may continue to
> try and create a model that has the issue as time permits.
>
> Scott
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Davis, Timothy S CTR comnavairsyscom]

Robert

I'd agree that I'm dealing with a driver bug.  I'm just not sure what the bug 
is.  I think we are working in a underspecified area of OpenGL when dealing 
with mipmap levels smaller than the compression block size.  However, I know 
that my driver generates 2x2 and 1x1 mipmaps for hardware generated compressed 
textures and this would suggest that it should happily work with these levels.

I don't agree that it is unrelated to the OSX driver issue.  Certainly the 
drivers are different and the symptoms may be different.  But they both appear 
to touch the same question; what happens with mipmaps smaller than the block 
size.  I don't have access to an OSX machine however, so I cannot investigate 
this claim further.

I have not tried different driver/hardware/OS combinations.  I'd agree that 
this would be useful, but I'm somewhat limited in how far I can go with this.

I'd agree that a change to the core OSG is not warranted at this time.  The 
models that cause the problem are not distributable.  I may continue to try and 
create a model that has the issue as time permits. 

Scott




smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Davis, Timothy S CTR comnavairsyscom]

smime.p7m
Description: S/MIME encrypted message
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Davis, Timothy S CTR comnavairsyscom]

Sorry.  It keeps trying to encrypt the message.

Robert

While continuing to build a model that results in the problem, I discovered 
something I didn't see before.  The IVE model had an incorrect number of mipmap 
levels (it had 8) for a 32x32 texture.  It makes sense that glTexStorage2D 
would generate INVALID_OPERATION in this case.  Rebuilding the model from a 
source with uncompressed textures and recompressing the textures worked.  The 
original model was converted with a much older version of OSG, pre OSG 3 for 
sure.

So I was barking up the wrong tree:)

That addresses my specific issue without needing a change to OSG 3.4.0.  
However, I still think it is worth trying for the OSX case.


Trajce

In osg/Texture.cpp, function applyTexImage2D(), find the line:

useTexStorage &= sizedInternalFormat != 0;

add the following after the line:

if ( useTexStorage && compressed_image && numMipmapLevels > 2 )
{
numMipmapLevels -= 2;
}

This is clearly not production quality as it assumes block size is 4 and 
complete mipmaps to 1x1.  It should be enough to check the approach.  You may 
have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is 
incomplete, but I didn't have that issue.

Scott
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Robert Osfield]

Hi Scott,

Thanks for the follow up.

Could you post the whole modified file, this way we can avoid any possible
copy and past errors.

Thanks,
Robert.

On 24 September 2015 at 20:13, Davis, Timothy S CTR comnavairsyscom <
timothy.s.davis@navy.mil> wrote:

> Sorry.  It keeps trying to encrypt the message.
>
> Robert
>
> While continuing to build a model that results in the problem, I
> discovered something I didn't see before.  The IVE model had an incorrect
> number of mipmap levels (it had 8) for a 32x32 texture.  It makes sense
> that glTexStorage2D would generate INVALID_OPERATION in this case.
> Rebuilding the model from a source with uncompressed textures and
> recompressing the textures worked.  The original model was converted with a
> much older version of OSG, pre OSG 3 for sure.
>
> So I was barking up the wrong tree:)
>
> That addresses my specific issue without needing a change to OSG 3.4.0.
> However, I still think it is worth trying for the OSX case.
>
>
> Trajce
>
> In osg/Texture.cpp, function applyTexImage2D(), find the line:
>
> useTexStorage &= sizedInternalFormat != 0;
>
> add the following after the line:
>
> if ( useTexStorage && compressed_image && numMipmapLevels > 2 )
> {
> numMipmapLevels -= 2;
> }
>
> This is clearly not production quality as it assumes block size is 4 and
> complete mipmaps to 1x1.  It should be enough to check the approach.  You
> may have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is
> incomplete, but I didn't have that issue.
>
> Scott
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.

[Davis, Timothy S CTR comnavairsyscom]

smime.p7m
Description: S/MIME encrypted message
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Robert Osfield]

Hi Scott,

The compression code has been in place quite some while so I'm surprised to
see a report of problem now.  Did this work with previous drivers/OSG
versions/different hardware?

Could you provide a small example and explanation of how to reproduce it so
others can see if they can reproduce the problem?

Thanks,
Robert.

On 22 September 2015 at 20:51, Davis, Timothy S CTR comnavairsyscom <
timothy.s.davis@navy.mil> wrote:

> I had an issue with OSG 3.4.0 when using a compressed 32x32 texture
> causing an INVALID_OPERATION in Texture::applyTexImage2D_load when calling
> glCompressTexSubImage2D.  This is called only when the texture storage
> object is used.  This resulted in the texture rendering as black.  Note
> that the texture was loaded from a IVE file created with an earlier version
> of OSG.
>
> After some investigation, I suspected that a possible cause was that the
> texture included mipmaps down to 2x2 and 1x1 in size.  The S3TC compression
> being used has a block size of 4 so cannot be used for these small mipmap
> levels.  Modifying numMipmapLevels by subtracting 2 if the image is
> compressed and using texture storage corrected the problem.  However this
> is likely not the best solution.
>
> My limited knowledge of OpenGL and this error suggests that this may be
> highly dependent on the OpenGL implementation.  I had several other
> compressed textures larger than 32x32 with mipmaps down to 2x2 and 1x1 that
> worked fine without this change.  The OpenGL documentation (see
> EXT_texture_compression_s3tc among others) however states that if the width
> or height are not multiples of 4 then the result is an INVALID_OPERATION.
> This can go unnoticed when not using a texture storage object.  But with
> the texture storage object, the error was generated when loading the full
> texture (i.e. level 0).
>
> If my understanding is correct, others may have had similar issues with
> compressed textures with mipmaps. They have worked around the issue by
> disabling mipmaps for compressed textures in ReaderWriterDDS for example.
> If the above holds true, then it may point to the underlying problem.
>
> Windows 7 64-bit, nVidia Driver 352.86, OSG 3.4.0
>
> Scott
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.

[Davis, Timothy S CTR comnavairsyscom]

Robert

Sorry for the bad posting of my last message.  I'll repeat here and update with 
new information.

The code in question was added sometime during OSG 3.3.x development.  It was 
not in OSG 3.2.1.  I just recently jumped from 3.2.1 to 3.4.0 for my 
application which is when I ran into the problem.  It worked fine with OSG 
3.2.1.  In particular, it appears to be the added support for texture storage 
objects and not specifically "compressed texture support".  I noted the call 
that gave the error was glCompressTexSubImage2D.  However I should point out 
that I determined this using gDEBugger.  My version doesn't seem to understand 
the texture storage extension.  So the error may have been generated by the 
earlier call to setup the texture storage.  I checked into this and indeed an 
INVALID_OPERATION was generated by the call to glTexStorage2D. 

In addition, on my machine the problem doesn't affect all compressed textures 
with mipmaps.  The model that first caused the problem had several such 
textures, but only a small 32x32 texture resulted in a problem.  I have no idea 
why this would be the case.  However I remember others reporting issues with 
loading DDS textures and working around it by commenting out the following line 
in ReaderWriterDDS:
If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets);
Commenting that line out would appear to disable mipmaps for compressed 
textures and avoid the problems I've indicated.  This older problem was 
reported only on OSX, but may be related.  This type of changed made to the IVE 
loader would also have fixed my problem at the expense of disabling mipmaps.

Looking at a different model, the one problem texture was 128x128.  So there 
appears to be nothing special about the size.  I did see that the rendering 
result for the models that have the problem is different between using the 
fixed-function pipeline and a shader.  With the FFP, the rendering appears 
correct, though the INVALID_OPERATION error is generated.  With a shader, the 
textures rendered black.

I looked at making a simple model that would reproduce the problem.  However, 
I've failed to create such a model.  It just always works with no render 
problems or OpenGL errors.

For my application, I've worked around the problem by reducing the number of 
mipmap levels to avoid using levels smaller than the compression block size.  
So I consider the problem fixed for me.  However, I feel this is information 
that you and the rest of the community can use.


Scott



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Davis, Timothy S CTR comnavairsyscom]

I had an issue with OSG 3.4.0 when using a compressed 32x32 texture causing an 
INVALID_OPERATION in Texture::applyTexImage2D_load when calling 
glCompressTexSubImage2D.  This is called only when the texture storage object 
is used.  This resulted in the texture rendering as black.  Note that the 
texture was loaded from a IVE file created with an earlier version of OSG.

After some investigation, I suspected that a possible cause was that the 
texture included mipmaps down to 2x2 and 1x1 in size.  The S3TC compression 
being used has a block size of 4 so cannot be used for these small mipmap 
levels.  Modifying numMipmapLevels by subtracting 2 if the image is compressed 
and using texture storage corrected the problem.  However this is likely not 
the best solution.

My limited knowledge of OpenGL and this error suggests that this may be highly 
dependent on the OpenGL implementation.  I had several other compressed 
textures larger than 32x32 with mipmaps down to 2x2 and 1x1 that worked fine 
without this change.  The OpenGL documentation (see 
EXT_texture_compression_s3tc among others) however states that if the width or 
height are not multiples of 4 then the result is an INVALID_OPERATION. This can 
go unnoticed when not using a texture storage object.  But with the texture 
storage object, the error was generated when loading the full texture (i.e. 
level 0).

If my understanding is correct, others may have had similar issues with 
compressed textures with mipmaps. They have worked around the issue by 
disabling mipmaps for compressed textures in ReaderWriterDDS for example. If 
the above holds true, then it may point to the underlying problem.

Windows 7 64-bit, nVidia Driver 352.86, OSG 3.4.0

Scott



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org