DXT, NPOT and mipmaps

[Iain Merrick]

Hi all,

I'm hitting a tricky failure case when combining NPOT textures, DXT compression and mipmaps.

The GL config I get via ANGLE says it supports both ANGLE_texture_compression_dxt and OES_texture_npot, but some of my glCompressedTexImage2D calls are failing.

Reading the ANGLE_texture_compression_dxt spec more closely, it says width and height must be 1, 2 or a multiple of 4. It looks like that is being applied strictly despite the presence of OES_texture_npot. The largest mipmap uploads succeed, but at some point in the chain the size isn't a multiple of 4, and the uploads start failing. Does this mean every mipmap needs to have power-of-two dimensions? Or is there some non-standard rounding rule for the smaller mipmaps, to keep the sizes a multiple of 4?

The hardware seems to be capable of full NPOT DXT textures in a normal desktop OpenGL context. The data is obviously padded out to 4x4 blocks, but width and height can take any value and it all just works. But I'd prefer to use ANGLE as GL is flaky on certain machines in other ways. Is there any way to get the same behaviour out of ANGLE? Or is this a Direct3D limitation, maybe?

Any advice appreciated!

Iain

[Iain Merrick]

I decided to take the hit of just working with the lowest common denominator, and resized all my images to POT dimensions.

I'd still be interested to know the answer, though! Anyone?

Iain

[Geoff Lang]

Sorry for the late reply.  Something seems off about this, maybe our validation is not completely correct.  Could you file a bug (https://bugs.chromium.org/p/angleproject/issues/entry) about this?  Copy-pasting the post above would be fine.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Iain Merrick]

OK, I'll do that when I have time. Thanks!

[Shannon Woods]

It's a bit subtle, but OES_texture_npot can't actually be assumed to enable non-power-of-two compressed textures. In the ES 2.0.25 spec, it's noted that "Specific compressed internal formats may impose format-specific restrictions on the use of the compressed image specification calls or parameters. For example, the compressed image format might not allow width or height values that are not a multiple of 4. Any such restrictions will be documented in the extension specification defining the compressed internal format; violating these restrictions will result in an INVALID_OPERATION error." (sec 3.7.3, Compressed Texture Images). The OES_texture_npot extension doesn't remove this reference, and the ANGLE_texture_compression_dxt extensions don't describe an interaction with OES_texture_npot, so the restrictions they impose aren't affected by that extension. (In contrast, EXT_texture_compression_s3tc describes an interaction with ARB_texture_non_power_of_two. This is how the interaction would need to be specified if ANGLE_texture_compression_dxt were to allow NPOT textures.)

Geoff, I don't remember-- does ANGLE support D3D9 devices with only conditional NPOT support? NPOT dxt textures would be problematic there, and that may have been the original source of the restriction, but conditional NPOT also poses problems for other aspects of texturing, so I'm not sure whether we ever supported it or not.

On Tuesday, June 28, 2016 at 3:07:52 PM UTC-4, Geoff Lang wrote:

Sorry for the late reply.  Something seems off about this, maybe our validation is not completely correct.  Could you file a bug (https://bugs.chromium.org/p/angleproject/issues/entry) about this?  Copy-pasting the post above would be fine.

[Iain Merrick]

Yes, ANGLE_texture_compression_dxt is ambiguous. Without the interaction with the NPOT extension clarified, "1, 2 or a multiple of 4" could force all the larger mipmaps to be powers of 4.

If the spec can be clarified, any of the following would be OK:

1. Clarify that only POT textures are supported.

2. Allow full NPOT support (if the appropriate extension is available) as per EXT_texture_compression_s3tc

3. Specify it to behave the same way as D3D9

I guessed (3) might be the way it's actually coded, so I hunted around for Direct3D specs, but I couldn't find any useful info there either!

[Geoff Lang]

For D3D9, it's possible that NPOT isn't supported (check here).  I don't have any stats on the real-world support though.

--

[Geoff Lang]

I think we  would be able to support the full EXT_texture_compression_s3tc on the D3D11 and GL backends.