[Mesa-dev] [PATCH v3] i965: Fix ETC2/EAC GetCompressed* functions on Gen7 GPUs

[Eero Tamminen]

Hi,

On 04.05.2018 14:11, Eleni Maria Stea wrote:
> Thanks for your feedback,
> On Thu, 3 May 2018 13:30:38 +0300
> Eero Tamminen <eero.t.tamminen at intel.com> wrote:
>> On 02.05.2018 20:19, Matt Turner wrote:
>>> On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea <estea at igalia.com>
>>> wrote:
>>>> Gen 7 GPUs store the compressed EAC/ETC2 images in other
>>>> non-compressed formats that can render. When GetCompressed*
>>>> functions are called, the pixels are returned in the
>>>> non-compressed format that is used for the rendering.
>>>>
>>>> With this patch we store both the compressed and non-compressed
>>>> versions of the image, so that both rendering commands and
>>>> GetCompressed* commands work.
>>>>
>>>> Also, the assertions for GL_MAP_WRITE_BIT and
>>>> GL_MAP_INVALIDATE_RANGE_BIT in intel_miptree_map_etc function have
>>>> been removed because when the miptree is mapped for reading (for
>>>> example from a GetCompress* function) the GL_MAP_WRITE_BIT won't
>>>> be set (and shouldn't be set).
>>>>
>>>> Fixes: the following test in CTS for gen7:
>>>> KHR-GL45.direct_state_access.textures_compressed_subimage test
>>>>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104272
>>>
>>> I think you can add
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81843
>>>
>>> as well :)
>>
>> This is really lovely feature.
>>
>> Compressed texture formats are used to:
>> 1. Reduce disk / network usage for the application install
>> 2. Increase run-time performance (by reducing required bandwidth)
>> 3. Reduce program memory usage
>>
>> At the cost of worse texture quality.
>>
>> Mesa transparently converting ETC to uncompressed data on platforms
>> that don't support ETC in HW, means that application doesn't get 2),
>> just worse texture quality, although some applications would have
>> capability to fall back to another (HW supported) texture compression
>> format.

Examples of these are GLBenchmark and GfxBench benchmarks GLES versions.

(First one defaults to ETC1, but can use also DXT if ETC is not
available.  GfxBench v5 defaults to ASTC/ETC2, but can use also DXT,
if those textures are shipped with it.  DXT is the default for the GL
version.)


>> And this new patch means that instead of 3), memory usage actually
>> _increases_ compared to application using non-compressed textures
>> directly.
>>
> 
> You are right about the memory usage and about the purpose of the patch.

This was bit of a cry for "why the world couldn't be a better place?".
I know hoping for a better solution for this when it requires also
users of the driver to do something extra, is a bit desperate...


>> Some (many?) applications might fail to run if ETC isn't supported, so
>> I  understand why this feature is done, but it would be nice to have
>> some better way to handle it.
>>
>> Maybe some new extension that can be used by future game engines &
>> application toolkits to query which of the compressed texture formats
>> are faked, so that they can instead select a compression format that
>> actually provides run-time benefits?
> 
> After having a look I think that we already have an extension for that
> type of query: the ARB_internalformat_query2. We are not sure if the
> existing queries would fit, but in case they don't we think that the
> new extension would rather add more queries to this one than introducing
> new methods. What do you think?

You mean returning CAVEAT_SUPPORT in params for compressed formats
which are transparently converted to uncompressed data?

That API's not available for GLES v2, where I think ETC is most widely
used, so it would be more of a solution for GLES v3.x applications only.
Sounds OK to me.

Hardest part will be propagating use of this query to engines & toolkits
that would benefit from using it. :-)


	- Eero