KTX2Loader: Fix ETC1S/UASTC prioritization#31871
Conversation
Due to a historical accident, the list of formats for ETC1S was sorted using UASTC priority. This change fixes that. However, this exposes a problem that already exists for UASTC to ETC1S as well: on Linux, Mesa drivers for various Intel and AMD GPUs expose support for ETC2 and ASTC extensions even if the hardware does not support them, as part of GLES compatibility. When a texture with an emulated format is uploaded, the driver runs a very expensive CPU side decompression; this runs on the main thread and causes performance and memory issues. When using Chrome based browsers, ANGLE filters out ASTC and ETC extensions for us; we now detect Gecko based browsers like Firefox that don't use ANGLE and do this filtering ourselves. In principle, it is possible for GPUs to support all formats - notably, Safari exposes all formats on macOS when using Apple Silicon hardware, as it genuinely supports all possible formats. In this case we still should prefer native (ASTC/ETC2) format targets as they are faster to transcode to. A corner case is a combination of Firefox / Asahi Linux on Apple Silicon hardware; in the future it might be possible to detect the unmasked vendor to disambiguate, but even that combination will simply use BC7 for UASTC or dual-slice ETC1S which is probably reasonable.
donmccurdy
left a comment
There was a problem hiding this comment.
Made a quick test at https://jsfiddle.net/donmccurdy/bkr3q8mc/ — prints navigatior.platform and whether Firefox is detected (true/false) — and as expected the Linux+Firefox checks return false on devices I have available. That's as expected, I don't have a Linux device currently.
Thank you @zeux!
|
@zeux hi zeus after this update ktx2 etc1 decode is very slow on my Linux Chrome 148.0.7778.215 (Offizieller Build) (64-Bit) Chrome than the decode is much faster |
|
This sounds like on your version of Chrome, the same problem as I noted existed in Firefox, was happening too. In my testing this was not the case but perhaps Angle folks removed the workaround since. You can try removing this part If that doesn't help, you'd need to find out which formats are supported and which are being selected for decoding to investigate this; I don't have AMD HW to test this at the moment. Specifically, logging all attributes of workerConfig would help, as well as a WebGL report for WebGL2 from https://webglreport.com/?v=2 |
|
Yeah this report contains WEBGL_compressed_texture_etc which is not supported by this GPU, and since you're using Mesa drivers, they would do the same slow software decoding that happened in Firefox for me when this PR was created. Does removing the Firefox user agent test from this patch fix the slowdown? |
|
looks like i had to add this.workerConfig.etc1Supported = false; works than with: |
|
Makes sense; I think in my case ETC1 wasn't marked as supported but in your case the browser reports both ETC1 & ETC2 as supported; neither are actually supported in hardware, and the ETC1S priority table says that we should try ETC2 & ETC1 before considering other formats. Would you mind submitting the fix (without logging) as a pull request? |
|
yes can do this tomorrow, but i wonder if this could have problemns on other plattforms too? or nvidia we should enable? |
|
The code currently doesn't check the vendor; while in my case the vendor was also AMD, I know this also affects Intel. I'm not sure about NVidia but I think maybe the best approach is to adjust the code to not check the browser and to disable ETC1; the worst case scenario here is that we have a vendor (NV?) that reports both formats and actually supports them, but then we go through ETC1S => BC transcoding path instead of through ETC1S => ETC2 which is potentially a little faster? I don't think it's too bad and we should probably err on the side of not running into a very expensive emulated software encoding here :) And this is Linux specific anyhow, so it's still narrowly scoped. So I would suggest not adding vendor checks or other platform checks, until we get specific reports for anything else like a non-Linux system. |
Updated comments to clarify supported formats on Linux.after discussion mrdoob#31871 @zeux


Due to a historical accident, the list of formats for ETC1S was sorted using UASTC priority. This change fixes that.
However, this exposes a problem that already exists for UASTC to ETC1S as well: on Linux, Mesa drivers for various Intel and AMD GPUs expose support for ETC2 and ASTC extensions even if the hardware does not support them, as part of GLES compatibility. When a texture with an emulated format is uploaded, the driver runs a very expensive CPU side decompression; this runs on the main thread and causes performance and memory issues.
When using Chrome based browsers, ANGLE filters out ASTC and ETC extensions for us; we now detect Gecko based browsers like Firefox that don't use ANGLE and do this filtering ourselves.
In principle, it is possible for GPUs to support all formats - notably, Safari exposes all formats on macOS when using Apple Silicon hardware, as it genuinely supports all possible formats. In this case we still should prefer native (ASTC/ETC2) format targets as they are faster to transcode to. A corner case is a combination of Firefox / Asahi Linux on Apple Silicon hardware; in the future it might be possible to detect the unmasked vendor to disambiguate, but even that combination will simply use BC7 for UASTC or dual-slice ETC1S which is probably reasonable.
See #29730 (comment) for motivating profiles.
Fixes #29745