Bug 92193 - [SKL] ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture.compressed_astc_texture fails
Summary: [SKL] ES2-CTS.gtf.GL2ExtensionTests.compressed_astc_texture.compressed_astc_t...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Nanley Chery
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 92778
  Show dependency treegraph
 
Reported: 2015-09-30 11:11 UTC by Tapani Pälli
Modified: 2016-02-13 00:57 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tapani Pälli 2015-09-30 11:11:33 UTC

    
Comment 1 Tapani Pälli 2015-09-30 11:12:20 UTC
assigning to our ASTC guru, Nanley let me know if you need any help in reproducing this.
Comment 2 Nanley Chery 2015-09-30 22:38:49 UTC
Is there an error message associated with this failure? I'll attempt to reproduce this in the meanwhile.
Comment 3 Nanley Chery 2015-09-30 23:01:52 UTC
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.
Comment 4 Nanley Chery 2015-09-30 23:23:42 UTC
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?
Comment 5 Tapani Pälli 2015-10-01 05:49:46 UTC
(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?
Comment 6 Nanley Chery 2015-10-01 17:13:32 UTC
(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?
Comment 7 Tapani Pälli 2015-10-02 05:43:08 UTC
(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
Comment 8 Ian Romanick 2015-10-14 18:45:50 UTC
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.
Comment 9 cprigent 2015-10-23 14:26:09 UTC
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
Comment 10 cprigent 2015-11-01 13:11:28 UTC
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
Comment 11 Matt Turner 2016-01-18 19:58:12 UTC
(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?
Comment 12 Nanley Chery 2016-01-18 20:19:19 UTC
(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.
Comment 13 Marta Löfstedt 2016-01-19 15:00:13 UTC
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
Comment 14 Nanley Chery 2016-01-20 17:11:04 UTC
(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.
Comment 15 Marta Löfstedt 2016-01-22 15:24:36 UTC
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.
Comment 16 Nanley Chery 2016-01-22 19:07:55 UTC
The output in the TestResults.qpa file suggests that the failure only occurs for the 12x12 block format.
Comment 17 Marta Löfstedt 2016-01-26 15:16:37 UTC
Another odd observation, if I force the renderbuffer to I915_TILING_NONE in intel_miptree_create_for_bo, the tests pass.
Comment 18 Marta Löfstedt 2016-01-27 12:08:47 UTC
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.
Comment 19 Marta Löfstedt 2016-01-27 15:01:38 UTC
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.
Comment 20 Nanley Chery 2016-01-28 18:26:48 UTC
(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.
Comment 21 Nanley Chery 2016-01-28 18:36:26 UTC
(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.
Comment 22 Nanley Chery 2016-01-29 01:14:26 UTC
(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.
Comment 23 Marta Löfstedt 2016-01-29 08:11:04 UTC
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.
Comment 24 Nanley Chery 2016-02-08 22:34:35 UTC
The patches for the fix are here: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107025.html
Comment 25 Marta Löfstedt 2016-02-09 09:09:57 UTC
Thanks Nanley,

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

This Bug should be close when the patches are merged.
Comment 26 Nanley Chery 2016-02-09 23:12:31 UTC
The patches have been merged. Thanks for the help Marta.
Comment 27 Nanley Chery 2016-02-13 00:57:11 UTC
(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?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.