minimal wasm build for glTF extension support

[andreasplesch]

We are trying to get a sense of what a minimal libktx.js/wasm build would look which only include the features needed to support the glTF basisu/ktx2 extension.

The current libktx.js and libktx.wasm are 900kb combined which is larger than complete 3d js frameworks in their entirety.

I think these builds are read only/decode only already but hopefully there would be opportunities to reduce library size much further. So any guidance or examples for limited builds would be welcomed.

https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/build/basis_transcoder.wasm is 460kb which is also huge. I think these transcoders supersede the transcoders built into libktx ? This also appears to have ktx2 parsing.

https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/CMakeLists.txt#L44 has a list of compiler target options which may already be a minimal set for glTF support ? Of course, this is another repo but the repos seem closely related.

We are aware of the Three and Babylon implementations but would be happy to reduce performance/quality or even support for some formats in exchange for less complexity and code size.

So any feedback or thoughts are much appreciated, Andreas

[MarkCallow]

Most people working in JavaScript write their own file parser and use the
KTX-Software-4.3.0-alpha3-Web-msc_basis_transcoder.zip package this project provides. The zipped file is 211kb.
This uses the same transcoder source as basis_transcoder.wasm but does not have any container parsers (.ktx2 or .basis). Also it contains only transcoders to formats supported by WebGL. The code is incorporated in KTX-Software via git subrepo.

There is also a collection of transcoders handwritten in wasm downloadable from https://github.com/KhronosGroup/Basis-Universal-Transcoders. Currently only UASTC to ASTC, BC7, R8, RG8, and RGBA8 transcoding is supported. I don't know the exact size but they should be smaller than the equivalents from msc_basis_transcoder.

The release package of KTX-Software-4.3.0-alpha3-Web-libktx.zip contains the full libktx compiled to wasm so includes the ASTC, ETC1S/Basis-Lz and UASTC encoders and zstd and zlib deflators as well as functions for assembling and writing KTX files. The zipped file is 338kb. It is possible to build to build with Emscripten the read-only library libktx_read and to omit ktx v1 support from it as these are CMake options. The result should be a lot smaller. I'd be happy to accept a PR to add such a built to the release assets.

[andreasplesch]

Thank you much for the comprehensive summary of options. I used unzipped sizes because the comparison is with unzipped but minified framework totals which is what is used to balance overall functionality with code size.
It may be an option to only support ASTC as GPU format since it appears to be fairly widely support across platforms, and depend on fallback or warnings for other cases. Is it possible at all to transcode ETC1S/Basis-Lz to ASTC ?

Do you think it would be possible with reasonable effort to build such a further reduced libktx_read ? I may try and any pointers would be much appreciated.

I tried some emscripten building with https://github.com/BinomialLLC/basis_universal/blob/master/webgl/transcoder/ and will try libktx_read without ktx1 support here first as well.

[MarkCallow]

It may be an option to only support ASTC

If ASTC is sufficient you may want to work with @wasimabbas-arm who is preparing to propose a texture_ASTC extension to the glTF WG. The objection most likely to be raised is that it is not cross platform so data to the contrary will be welcome.

The advantage is that no transcoder is needed. The disadvantage is larger file & transmission sizes, compared to UASTC, because the encoder does not currently have RDO (rate-distortion optimization) to condition its output for more effective lossless supercompression.

Is it possible at all to transcode ETC1S/Basis-Lz to ASTC

Yes. Both ETC1S/Basis-Lz and UASTC can be transcoded to ASTC.

Do you think it would be possible with reasonable effort to build such a further reduced libktx_read ? I may try and any pointers would be much appreciated.

Yes. libktx.js currently links with the read -only library so you don't need to worry about that. See line 838 in the root CMakeLists.txt. You can set the following CMake config options of OFF to remove the corresponding features from the library.

• KTX_FEATURE_GL_UPLOAD
• KTX_FEATURE_KTX1

GL_UPLOAD adds the function to upload the texture to WebGL via Emscripten's OpenGL ES support. You may want to use this.

To remove additional transcoders you will need to edit the root CMakeLists.txt and add desired defines after line 580. A list of all the available transcoder defines is given starting at line 528. I've encountered unexpected (and unintended) dependencies between transcoders in the BasisU code in the past so there is a chance it will not go smoothly.

The easiest way to build the wasm stuff is to installer docker then use ci_scripts_build_wasm_docker.sh. You'll need to modify it slightly to accept and provide to CMake the values for KTX_FEATURE_GL_UPLOAD and KTX_FEATURE_KTX1.

[andreasplesch]

Thanks again, especially for the detailed build explanations. As a first step, I could use the docker build script on codespaces successfully and will go from there.
The focus on ASTC emerged from caniuse statistics which shows the webgl extension to be available on most platforms, compared to other compressed formats.

[andreasplesch]

Unfortunately, I did not get very far after adding -D KTX_FEATURE_KTX1=OFF \ to the build_wasm_docker.sh script.
The result is this linker error:

[ 92%] Building CXX object CMakeFiles/ktx_js.dir/interface/js_binding/ktx_wrapper.cpp.o
[ 93%] Linking CXX executable libktx.js
cache:INFO: generating system asset: symbol_lists/d4e0b0b7b0c493e082d96e029d9355f9a8a18614.json... (this will be cached in "/emsdk/upstream/emscripten/cache/symbol_lists/d4e0b0b7b0c493e082d96e029d9355f9a8a18614.json" for subsequent builds)
cache:INFO:  - ok
wasm-ld: error: libktx_read.a(texture.c.o): undefined symbol: ktxTexture1_constructFromStreamAndHeader

I could run build_linux.sh with KTX_FEATURE_KTX1=OFF successfully. I think that ktx_wrapper.cpp may look for ktxTexture1 when it is calling ktxTexture_CreateFromMemory ? I tried to modify ktx_wrapper.cpp to only use ktxTexture2 but could not quite manage and this would probably would not be the correct approach.
Any pointers or ideas would be very welcome.

[andreasplesch]

I could update ktx_wrapper.cpp to only use ktx2 texture functions, after also including ktx2Texture_Destroy in ktx.h, in my glTFwasm branch. This allowed KTX_FEATURE_KTX1=OFF in the wasm build to succeed. Together with only enabling BASISD_SUPPORT_UASTC=1 and disabling all other formats this brings down wasm size to 417KB. The msc_basis_transcoder.wasm transcoder only size is 199KB. KTX2 parsing may not need 117KB wasm, so perhaps there are more opportunities.

[andreasplesch]

I could also use KTX_FEATURE_GL_UPLOAD=OFF but it did not make a difference for the generated wasm code, presumably because the wrapper does not actually use any related code, eg. the glUpload() function is commented because it is not clear how to use the uploaded texture.

I also tried recommended em++ compiler/linker options -Oz and --closure 1 which significantly reduced code size to ca. 330KB, and 60KB for the .js interface.

[MarkCallow]

I am sorry for my lack of response over the past weeks.

There should probably be stub functions that return KTX_INVALID_OPERATION for the ktxTexture1 functions when KTX_FEATURE_KTX1 is OFF. This will be better than sprinkling ifdefs around all the callers.

I don't understand what you mean about the glUpload function in the wrapper. It is not commented out. It does work. The comment about not knowing how to find the texture created by the Emscripten OpenGL ES emulator is out of date. The function contains the solution. That said, I can't explain why setting KTX_FEATURE_GL_UPLOAD=OFF has no effect on the generated code.

[andreasplesch]

Apologies for the confusion about glUpload. You are completely right. I had commented it out myself. I may be able to give the stub functions a try.