Ericcson Texture Compression support?

[chrishancox]

Hi there,

I note that a lot of 3D applications that are useful under GL4ES use S3 texture compression which is usually decompressed at runtime. Is it possible that GL4ES could have ETC (Ericcson Texture Compression) support, so that it could encode the now uncompressed textures to ETC to improve performance? On a lot of hardware, uncompressed textures run slow.

[ptitSeb]

Just ETC can only be used on a subset of S3TC.

ETC only works on RGB texture, not RGBA, which may limit greatly the number of texture converted.

But yes, in theory, it can work. I'll add that to my (long) todo.

(of course ETC2 add RGBA support, but not all hardware implement it)

[chrishancox]

I just realised actually ptitSeb that rPi4 actually seems to support ASTC compression judging by glxinfo so that might be a better target as I imagine it supports RGBA and by the time you actually write any code, be more relevant also.

[icecream95]

AFAICT, the RPi doesn't have hardware support for ASTC, but the drivers do support decompressing ASTC in software, but then there's no advantage to using it over uncompressed textures.

ASTC is also big and complex and has possible patent issues.

Any hardware supporting ASTC will also support ETC2, so RGBA isn't a reason to use ASTC.

[ptitSeb]

I started looking at adding, at least, support for ETC (1) texture compression, for the S3TC texture without alpha. For now, my first issue is to find (or build) a compressor (with a licence compatible with the MIT one used on gl4es).

[chrishancox]

I note that ETCPACK exists on GitHub: https://github.com/Ericsson/ETCPACK

Perhaps it could be called as an external library at runtime if it is installed on the system, and let ETCPACK handle the compression?

Since this could be quite slow, perhaps the files could be cached to disk, similarly to how e.g Steam & device drivers cache GLSL shaders rather than always building every run.

(I apologise if this seems lofty in aspiration - my coding is limited to a few things, on my own GIT there is a version of OpenCity with a few additional industries added, but this was mostly copy & paste C++ code)

[mittorn]

Even if compression is very slow, we may compute checksum and cache compressed textures like it done for shaders. It is better than downsampling dxt textures to RGBA4444/RGB565 4444 REALLY looks ugly

[ptitSeb]

Yeah, I know 4444 looks bad most of the time. But again, ETC1 doesn't support RGBA, only RGB, and ETC2 is not universaly supported. (Also, yeah, an optionnal cache can be done, why not). Also, convertion to 16bits textures can be avoid with LIBGL_AVOID16BITS=1 env. var.

[mittorn]

I do not know why skyboxes in XashXT use rgba4444 unless AVOID16BITS is set, but it is solid and RGB565/ETC1 may be used. It may be detected during conversion

[ptitSeb]

@mittorn I have just pushed a commit that should improve a bit the downgrading. If there is no transparency, it should use RGB565 now. It use 565/5551/4444 depending on the data...