glCompressedTexImage2D results in wrong enum about angle HOT 9 CLOSED

We fixed this temporarily by adding extensions->textureCompressionDXT5 = true;

In the libGLESv2/renderer/d3d/d3d11/renderer11_utils.cpp.

from angle.

I will look into this today. I am glad that you are unblocked for now.

from angle.

I cannot reproduce your error. DXT3 and DXT5 seems to be reported as supported extensions and glCompressedTexImage2D is allowing the formats to be used.

The helper function DetermineDXT5TextureSupport( ) in src\libglesv2\caps.cpp controls the true/false setting for compressed textures of that format. Could you step into this function and then into GetFormatSupport( ) and tell me what gets returned in 'TextureCaps'.

it should read:
texturable = true
filterable = true
renderable = false

The incoming parameter 'requiresRendering' to GetFormatSupport should be set to false which will result in the format being supported.

from angle.

That's very interesting since the change I introduced was the only way to get passed the validation functions. Unfortunately I don't have access to the devices and computer that this was evaluated upon, but I will investigate further tomorrow. Until then, the devices (and only devices) that we've tried and got this reproduced consequently are: Nokia Lumia 520, Nokia Lumia 630 and Nokia Lumia 1520. We have only used the Release ARM versions and we built angle from source this morning.

I tried to follow the logic of the methods mentioned above but couldn't really figure out how the actual textureable setting was applied since all I could see in the source was the actual allocation of false in the constructor of the TextureCaps structure.

How am I supposed to be able to sleep now? :)

from angle.

So this is growing to be even more intriguing since this morning I was able to rebuild on a private machine and make a sample application verify that it doesn't generate the wrong enum.

Then I rebuilt on the actual development macine at work and still get the exact same behavior as earlier, wrong enum is thrown and all the dds images are rendered black (since the textures are empty).

An explanation on what impacts the DXT5 support would be really helpful since I can't really see any differences in the setup of the different solutions.

Regards

Johan Lindfors
//coderox

from angle.

I did a little test this morning to follow a theory. You mentioned that you were seeing this only with devices. That clued me into thinking that this could be a possible feature level 9_3 specific code path. The reason your separate test you performed probably worked is you were not limited to 9_3 and got the full feature level support by default.

I changed my test application to force limit to feature level to 9_3 and got the same result as your device tests. These DXT formats should be supported on 9_3 so there is a bug here that I need to look into.

I will dig more into this today. I am hoping that it is an easy fix. I will keep you posted.

from angle.

A small update for you. I have found the root cause of the format being filtered out of the supported list.

In the function 'gl::TextureCaps GenerateTextureFormatCaps()' located in src\libglesv2\renderer\d3d\d3d11\renderer11_utils.cpp, the device is queried for support of the target format.

This function sets a 'textureable' bool based on the reported device support including TEXTURE2D, TEXTURE3D, and TEXTURECUBE. I noticed that FL9_3 only reported support for TEXTURE2D and TEXTURECUBE. Missing TEXTURE3D forces 'textureable' to be false which eliminates the format as supported.

I need to do some more testing and craft up a proper fix to ensure that FL9_3 gets the proper reported format support in this code path.

from angle.

I just updated future-dev with a fix that will enable you to use compressed textures again.

from angle.

Thanks for the fix!

I can acknowledge that the fix works fine!

from angle.