Bug 81843 - [SNB IVB HSW] ETC2 textures are not returned as compressed images
Summary: [SNB IVB HSW] ETC2 textures are not returned as compressed images
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 10.2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2014-07-28 16:22 UTC by Jon Ashburn
Modified: 2019-02-27 08:59 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Description Jon Ashburn 2014-07-28 16:22:07 UTC
i965 driver stores ETC2 textures  as uncompressed since Gen 7.5 and earlier GPUs don't support ETC2 format.  glGetCompressedImage() of these ETC2
textures should cause a compression to ETC2 format to occur before returning data
to the client.  This compression on read of ETC2 texture doesn't appear to be happening.
Comment 1 Eleni Maria Stea 2018-05-03 07:51:51 UTC
There has been some workaround related to this issue:

There is a patch proposal awaiting review at:

that can be tested quickly with this test program:

With the patch, Gen7 GPUs that cannot compress ETC2 images, store both the compressed and the non-compressed data of the ETC2 images in two different miptrees. Then, the non-compressed data are used for the rendering like before and the compressed data for the GetCompressed* functions to work properly.

see also: https://bugs.freedesktop.org/show_bug.cgi?id=104272
Comment 2 Eleni Maria Stea 2018-05-03 08:07:32 UTC
To make things a little bit more clear: in the patch above we don't implement the compression, it was a workaround for the CTS tests (KHR-GL46.direct_state_access.textures_compressed_subimage) to pass.
Comment 3 oleksandr.nikitin 2018-05-15 08:16:05 UTC
This test program shows with mesa Mesa 17.2.8 and 18.1.0 the bug is reproducible.
With mesa Mesa 18.2.0 the bug does not reproduce.  

Information on the configuration of a computer: 
- Ubuntu Linux Version 16.04 64-bit
- 4.13.0-38-generic
- Intel® HD Graphics 620 (Kaby Lake GT2)
- Intel® Core™ i7-7500U CPU @ 2.70GHz × 4
Comment 4 Nanley Chery 2019-02-16 00:01:44 UTC
This should be fixed by the following commit:

commit d8eb7287fe82e74da8f2938e7190610d3ded0051
Author: Eleni Maria Stea <estea@igalia.com>
Date:   Fri Feb 15 15:29:41 2019 +0200

    i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.
    GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
    compressed EAC/ETC2 images to non-compressed RGBA images. When
    GetCompressed* functions were called, the pixels were returned in this
    RGBA format and not the compressed format that was expected.
    Trying to fix this problem, we use a secondary shadow miptree to store the
    decompressed data for the rendering and the main miptree to store the
    compressed for the Get functions to work. Each time that the main miptree
    is written with compressed data, we decompress them to RGB and update the
    shadow. Then we use the shadow for rendering.
Comment 5 Paul 2019-02-18 12:57:03 UTC
Hi guys,
I just ran the compression-test and noted the next results:
When I run test on Intel® HD Graphics 4600 (Haswell) with master version of mesa - I see next response - "12 generic compressed texture formats available:
 086b0: GL_COMPRESSED_RGB_FXT1_3DFX (compressed format)
 086b1: GL_COMPRESSED_RGBA_FXT1_3DFX (compressed format)
 083f0: GL_COMPRESSED_RGB_S3TC_DXT1_EXT (compressed format)
 083f2: GL_COMPRESSED_RGBA_S3TC_DXT3_EXT (compressed format)
 083f3: GL_COMPRESSED_RGBA_S3TC_DXT5_EXT (compressed format)
 09274: GL_COMPRESSED_RGB8_ETC2 (compressed format)
 09278: GL_COMPRESSED_RGBA8_ETC2_EAC (compressed format)
 09270: GL_COMPRESSED_R11_EAC (compressed format)
 09272: GL_COMPRESSED_RG11_EAC (compressed format)
 09271: GL_COMPRESSED_SIGNED_R11_EAC (compressed format)
 09273: GL_COMPRESSED_SIGNED_RG11_EAC (compressed format)
 09276: GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2 (compressed format)
compressed_texture is not a compressed texture file, or is corrupted
failed to load texture compressed_texture"
I see the same response on 18.3.2 version of the mesa on this machine.

Also, I see the same response on Intel® UHD Graphics 620 (Kaby lake) and Intel® HD Graphics 3000 (Sandy Bridge) with 18.3.2 version and master's version of the mesa.
Please, confirm - is it correct?
Comment 6 Eleni Maria Stea 2019-02-26 17:03:19 UTC
Hi, yes that's normal, I am sorry :) I forgot I had pasted the link in this bug report and modified the test... 

So, new instructions:

git clone https://github.com/hikiko/test-compression.git

cd to the directory run make and
./test compressed/full.tex

you should see some mipmaps (it tests that we can create and display all the levels).


Then if you want to run the original test you have to checkout a previous commit:
git checkout a76e52b12bf54efdeb95b7f6d8ecfdcec0ab81ae
./test compressed_texture
./test compressed_texture -subtest
./test compressed_texture -copytest

the first checks GetCompressedTexImage you should see a texture and a message that submitted and retrieved data match.


the second checks the GetCompressedTextureSubImage you should see the previous texture and a red quad overwriting a region in the upper left corner + same message


and the third tests the CopyImageSubData and you should see a yellow quad where you would see the red before..


I hope that with these instructions you can run it, sorry that I modified it! :)
Comment 7 Paul 2019-02-27 08:59:40 UTC
Hi Eleni,
Thanks for the detailed instruction.
All looks correct. :)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.