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.tammi...@intel.com> wrote:
On 02.05.2018 20:19, Matt Turner wrote:
On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea <es...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
