Bug 92193

assigning to our ASTC guru, Nanley let me know if you need any help in reproducing this.

Is there an error message associated with this failure? I'll attempt to reproduce this in the meanwhile.

I was able to reproduce this. The error (paraphrased) is:

<Text>GTFFixedTestTextureCompressionASTCLDR::Apply/error: Required texture format 93[B0-BD] is not supported</Text>
<Text>GTFFixedTestTextureCompressionASTCLDR::Apply/error: Required texture format 93[D0-DD] is not supported</Text>

I'm looking this.

Looks like there's a bug in the CTS. It looks for the ASTC formats in the list returned by glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, ...). As mentioned in spec, the ASTC format enums won't be returned by this function:

Interactions with OpenGL 4.2

    OpenGL 4.2 supports the feature that compressed textures can be
    compressed online, by passing the compressed texture format enum as
    the internal format when uploading a texture using TexImage1D,
    TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
    Specification, subsection Encoding of Special Internal Formats).

    Due to the complexity of the ASTC compression algorithm, it is not
    usually suitable for online use, and therefore ASTC support will be
    limited to pre-compressed textures only. Where on-device compression
    is required, a domain-specific limited compressor will typically
    be used, and this is therefore not suitable for implementation in
    the driver.

    In particular, the ASTC format specifiers will not be added to
    Table 3.14, and thus will not be accepted by the TexImage*D
    functions, and will not be returned by the (already deprecated)
    COMPRESSED_TEXTURE_FORMATS query.

I'll send a patch upstream to fix this. Should I take any further steps?

(In reply to Nanley Chery from comment #4)
> Looks like there's a bug in the CTS. It looks for the ASTC formats in the
> list returned by glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, ...). As
> mentioned in spec, the ASTC format enums won't be returned by this function:
> 
> Interactions with OpenGL 4.2
> 
>     OpenGL 4.2 supports the feature that compressed textures can be
>     compressed online, by passing the compressed texture format enum as
>     the internal format when uploading a texture using TexImage1D,
>     TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
>     Specification, subsection Encoding of Special Internal Formats).
> 
>     Due to the complexity of the ASTC compression algorithm, it is not
>     usually suitable for online use, and therefore ASTC support will be
>     limited to pre-compressed textures only. Where on-device compression
>     is required, a domain-specific limited compressor will typically
>     be used, and this is therefore not suitable for implementation in
>     the driver.
> 
>     In particular, the ASTC format specifiers will not be added to
>     Table 3.14, and thus will not be accepted by the TexImage*D
>     functions, and will not be returned by the (already deprecated)
>     COMPRESSED_TEXTURE_FORMATS query.
> 
> I'll send a patch upstream to fix this. Should I take any further steps?

This sounds good, did you file a bug in Khronos bugzilla?

(In reply to Tapani Pälli from comment #5)
> (In reply to Nanley Chery from comment #4)
> > Looks like there's a bug in the CTS. It looks for the ASTC formats in the
> > list returned by glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, ...). As
> > mentioned in spec, the ASTC format enums won't be returned by this function:
> > 
> > Interactions with OpenGL 4.2
> > 
> >     OpenGL 4.2 supports the feature that compressed textures can be
> >     compressed online, by passing the compressed texture format enum as
> >     the internal format when uploading a texture using TexImage1D,
> >     TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
> >     Specification, subsection Encoding of Special Internal Formats).
> > 
> >     Due to the complexity of the ASTC compression algorithm, it is not
> >     usually suitable for online use, and therefore ASTC support will be
> >     limited to pre-compressed textures only. Where on-device compression
> >     is required, a domain-specific limited compressor will typically
> >     be used, and this is therefore not suitable for implementation in
> >     the driver.
> > 
> >     In particular, the ASTC format specifiers will not be added to
> >     Table 3.14, and thus will not be accepted by the TexImage*D
> >     functions, and will not be returned by the (already deprecated)
> >     COMPRESSED_TEXTURE_FORMATS query.
> > 
> > I'll send a patch upstream to fix this. Should I take any further steps?
> 
> This sounds good, did you file a bug in Khronos bugzilla?

I just filed the bug (and attached the patch) https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip. Is there anything else we should do?

(In reply to Nanley Chery from comment #6)
> (In reply to Tapani Pälli from comment #5)
> > (In reply to Nanley Chery from comment #4)
> > > Looks like there's a bug in the CTS. It looks for the ASTC formats in the
> > > list returned by glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, ...). As
> > > mentioned in spec, the ASTC format enums won't be returned by this function:
> > > 
> > > Interactions with OpenGL 4.2
> > > 
> > >     OpenGL 4.2 supports the feature that compressed textures can be
> > >     compressed online, by passing the compressed texture format enum as
> > >     the internal format when uploading a texture using TexImage1D,
> > >     TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
> > >     Specification, subsection Encoding of Special Internal Formats).
> > > 
> > >     Due to the complexity of the ASTC compression algorithm, it is not
> > >     usually suitable for online use, and therefore ASTC support will be
> > >     limited to pre-compressed textures only. Where on-device compression
> > >     is required, a domain-specific limited compressor will typically
> > >     be used, and this is therefore not suitable for implementation in
> > >     the driver.
> > > 
> > >     In particular, the ASTC format specifiers will not be added to
> > >     Table 3.14, and thus will not be accepted by the TexImage*D
> > >     functions, and will not be returned by the (already deprecated)
> > >     COMPRESSED_TEXTURE_FORMATS query.
> > > 
> > > I'll send a patch upstream to fix this. Should I take any further steps?
> > 
> > This sounds good, did you file a bug in Khronos bugzilla?
> 
> I just filed the bug (and attached the patch)
> https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip.
> Is there anything else we should do?

this is fine, I think we should keep this bug open until the issue is resolved in the test suite

There is an intentional divergence between desktop OpenGL and OpenGL ES on GL_COMPRESSED_TEXTURE_FORMATS.  We'll need to list the ASTC formats on OpenGL ES.

Fail on SKL-Y.
Test was Pass with Mesa 11.0.3.

Platform: SKY LAKE Y A0 
CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78  stepping: 3)
MCP : SKL-Y  D1 2+2 (ou ULX-D1)
QDF : QJK9 
CPU : SKL D0
Chipset PCH: Sunrise Point LP C1       
CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2
Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06
Software
BIOS : SKLSE2R1.R00.X097.B02.1509020030
ME FW : 11.0.0.1173
Ksc (EC FW): 1.19
Linux distribution: Ubuntu 14.04 LTS 64 bits
kernel 4.3.0-rc5-drm-intel-nightly+ (f14b17b) from git://anongit.freedesktop.org/drm-intel
commit f14b17b8639fb680c672d3d2f8d6414fcf0f82c4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Oct 16 19:27:49 2015 +0200
drm-intel-nightly: 2015y-10m-16d-17h-27m-10s UTC integration manifest
Mesa master commit 6f3954618b0fe273af76af79ce9ec56566b79b2a from http://cgit.freedesktop.org/mesa/mesa/
xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Libdrm - 2.4.65 from http://cgit.freedesktop.org/mesa/drm/
Libva - 1.6.1 from http://cgit.freedesktop.org/libva/
vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver
Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo
Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver

For information test is Pass on Mesa 11.0.4 + kernel 4.3.0-rc6-drm-intel-nightly+ (ab48d30) from git://anongit.freedesktop.org/drm-intel

(In reply to Nanley Chery from comment #6)
> I just filed the bug (and attached the patch)
> https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip.
> Is there anything else we should do?

The other three blockers of the ES3.1 tracker bug have outstanding patches, so this bug looks like it might be the last blocker.

I see that there has been some activity on the internal bug (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=14842). What's the status of this bug, Nanley?

(In reply to Matt Turner from comment #11)
> (In reply to Nanley Chery from comment #6)
> > I just filed the bug (and attached the patch)
> > https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip.
> > Is there anything else we should do?
> 
> The other three blockers of the ES3.1 tracker bug have outstanding patches,
> so this bug looks like it might be the last blocker.
> 
> I see that there has been some activity on the internal bug
> (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=14842). What's the status
> of this bug, Nanley?

The merge request has been made, and we're just waiting on someone to merge it.

There are still issues with ASTC test and GLES CTS. I applied Nanleys updated patch on ToT Khronos CTS, but I still fail when running ASTC test. However, I only fail with configs with specific surface sizes. For example:
Fail:
./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture* --deqp-surface-width=113 --deqp-surface-height=47
Pass:
./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture* --deqp-surface-width=64 --deqp-surface-height=64

(In reply to Marta Löfstedt from comment #13)
> There are still issues with ASTC test and GLES CTS. I applied Nanleys
> updated patch on ToT Khronos CTS, but I still fail when running ASTC test.
> However, I only fail with configs with specific surface sizes. For example:
> Fail:
> ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> --deqp-surface-width=113 --deqp-surface-height=47
> Pass:
> ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> --deqp-surface-width=64 --deqp-surface-height=64

I was able to reproduce this error. I'm looking into this.

This pass:
./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture* --deqp-surface-width=113 --deqp-surface-height=48
pass:
./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture* --deqp-surface-width=47 --deqp-surface-height=48
fail:
./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture* --deqp-surface-width=48 --deqp-surface-height=47

The texture size in the test is 48x48, so it appears that we fail when the height of the destination surface is less that the height of the texture, that is odd...

Checking the result log we fail with color (0,0,0) in all pixels at the destination. However, if I increase the width to lets say 96, I get nonsens colors for a while and the black.

The output in the TestResults.qpa file suggests that the failure only occurs for the 12x12 block format.

Another odd observation, if I force the renderbuffer to I915_TILING_NONE in intel_miptree_create_for_bo, the tests pass.

If I set: 
"config.window_height = level0_height -1;"

in piglit:
 tests/spec/khr_texture_compression_astc/khr_compressed_astc-miptree-array.c
the test fail.

The test pass with the default:
"config.window_height = level0_height + (level0_height >> 1);"

level0_height is the height of the texture in the piglit test.

I believe this reproduce the error in the CTS tests.

I am now questioning my previous comment. I now notice that it only fails at pixel (nn, 105), which is outside the height of my render target.

I will have to come up with a better piglit reproducer.

(In reply to Marta Löfstedt from comment #15)
> This pass:
> ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> --deqp-surface-width=113 --deqp-surface-height=48
> pass:
> ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> --deqp-surface-width=47 --deqp-surface-height=48
> fail:
> ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> --deqp-surface-width=48 --deqp-surface-height=47
> 
> The texture size in the test is 48x48, so it appears that we fail when the
> height of the destination surface is less that the height of the texture,
> that is odd...

Why must we be able to render into a surface with the dimension you've mentioned? With my current knowledge, I don't know if this failure is caused by us creating an invalid test case or if there's an API feature we're lacking in the driver.

(In reply to Nanley Chery from comment #12)
> (In reply to Matt Turner from comment #11)
> > (In reply to Nanley Chery from comment #6)
> > > I just filed the bug (and attached the patch)
> > > https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip.
> > > Is there anything else we should do?
> > 
> > The other three blockers of the ES3.1 tracker bug have outstanding patches,
> > so this bug looks like it might be the last blocker.
> > 
> > I see that there has been some activity on the internal bug
> > (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=14842). What's the status
> > of this bug, Nanley?
> 
> The merge request has been made, and we're just waiting on someone to merge
> it.

I should also add that this bug has been fixed in Mesa and so we aren't blocking ES3.1 conformance. We've also now realized that this is an issue in the desktop GL CTS, but as mentioned earlier, the upstream fix is awaiting a merge. 

Failures do occur when using a range of (potentially invalid) surface dimensions. I'm currently looking into this.

(In reply to Nanley Chery from comment #20)
> (In reply to Marta Löfstedt from comment #15)
> > This pass:
> > ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> > --deqp-surface-width=113 --deqp-surface-height=48
> > pass:
> > ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> > --deqp-surface-width=47 --deqp-surface-height=48
> > fail:
> > ./glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture*
> > --deqp-surface-width=48 --deqp-surface-height=47
> > 
> > The texture size in the test is 48x48, so it appears that we fail when the
> > height of the destination surface is less that the height of the texture,
> > that is odd...
> 
> Why must we be able to render into a surface with the dimension you've
> mentioned? With my current knowledge, I don't know if this failure is caused
> by us creating an invalid test case or if there's an API feature we're
> lacking in the driver.

Rendering into such dimensions is a conceptually supported by OpenGL, but there seems to be a bug in the test that causes it to fail. I found a fix and I'm currently double checking the reasoning behind it.

When applying for conformance the ./cts-runner is executed, this will run all GLES test with all EGL configs we "claim" to support with different settings. You will find the configurations for all the runs in cts-run-summary.xml in the folder with all the *qpa files produced by the cts-runner.

You can get a summary of your result by running the python script "verify_submission.py" on the folder of all the *.qpa files.

When running cts-runner, I noted that we only failed the 2 astc tests with configs using: --deqp-surface-width=113 --deqp-surface-height=47.

The patches for the fix are here: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107025.html

Thanks Nanley,

I confirm that issue is not reproducible with you patch-set.

This Bug should be close when the patches are merged.

The patches have been merged. Thanks for the help Marta.

(In reply to Tapani Pälli from comment #7)
> (In reply to Nanley Chery from comment #6)
> > (In reply to Tapani Pälli from comment #5)
> > > (In reply to Nanley Chery from comment #4)
> > > > Looks like there's a bug in the CTS. It looks for the ASTC formats in the
> > > > list returned by glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, ...). As
> > > > mentioned in spec, the ASTC format enums won't be returned by this function:
> > > > 
> > > > Interactions with OpenGL 4.2
> > > > 
> > > >     OpenGL 4.2 supports the feature that compressed textures can be
> > > >     compressed online, by passing the compressed texture format enum as
> > > >     the internal format when uploading a texture using TexImage1D,
> > > >     TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
> > > >     Specification, subsection Encoding of Special Internal Formats).
> > > > 
> > > >     Due to the complexity of the ASTC compression algorithm, it is not
> > > >     usually suitable for online use, and therefore ASTC support will be
> > > >     limited to pre-compressed textures only. Where on-device compression
> > > >     is required, a domain-specific limited compressor will typically
> > > >     be used, and this is therefore not suitable for implementation in
> > > >     the driver.
> > > > 
> > > >     In particular, the ASTC format specifiers will not be added to
> > > >     Table 3.14, and thus will not be accepted by the TexImage*D
> > > >     functions, and will not be returned by the (already deprecated)
> > > >     COMPRESSED_TEXTURE_FORMATS query.
> > > > 
> > > > I'll send a patch upstream to fix this. Should I take any further steps?
> > > 
> > > This sounds good, did you file a bug in Khronos bugzilla?
> > 
> > I just filed the bug (and attached the patch)
> > https://www.khronos.org/bugzilla/show_bug.cgi?id=1395 . Thanks for the tip.
> > Is there anything else we should do?
> 
> this is fine, I think we should keep this bug open until the issue is
> resolved in the test suite

I closed this bug because it was being tracked for GLES 3.1 conformance. The outstanding MR for the CTS will be an issue for the next GL version we try to reach conformance for. Is this a non-issue, or do you think I should reopen this and remove the tracking on it?