Before investigating further this topic I thought I might ask if on paper it is worth investigating.
My scene has one very large texture of 7000 x 7000 px, but is super simple with only a big mesh of 10000 vertices / faces that gets this texture applied to it. There is no light etc etc…
Besides advantage regarding texture size, RAM usage and CPU on loading, my question is do you think there will be significant performance improvements of the scene once loaded with this texture compressed instead of a JPG file ? Or once loaded on the GPU it is the same ?
Compressed texture are more gpu friendly as they are used compressed on GPU to. Caching, uploading and fetching might be faster to due to the reduced bandwith requirements:
Considering your use case of a unique texture, you could try and measure the cross device gain but I am not sure it would dramatically change your perf, it would still be better (though not significantly if you are bound somewhere else) but might lead to a reduced visual quality (artifacts) depending on the usage you have.
Ok many thanks for the feedback, I will update this topic when I try but I won’t priorize it for now. I guess the bottleneck is more on the mesh complexity.
Just to chime in here, I’ve been doing experiments using .ktx textures, and in general the results of using compressed textures are pretty impressive. First of all, when a texture is not compressed, the GPU doing a lookup needs to traverse every pixel to find the uv position for the shader. In a very large image that’s going to be slow. And before it can do this, it needs to uncompress the texture from whatever compression scheme it’s using, such as .png or .jpg. This will then be uploaded to the GPU where it’s stored in both GPU and CPU. A .basis or .ktx file, however, will store the compressed versions only on the GPU, and they won’t be uncompressed at all. When it’s time to look up the texture in the shader, it can uncompress the data in 4x4 blocks, which is much faster. Also, as you pointed out, the memory footprint is much smaller on compressed formats. In my tests, a crunched DXT texture takes up just 25% of the GPU memory that an uncompressed one does. And as we know, it doesn’t matter if we use JPG because it all has to be uncompressed to send to the GPU either way, so compressed textures are faster to load. On my test, load times were reduced by 50%.
So I think it’s well worth the effort. I’m not going with .basis right now, only because it’s not as well supported and the tooling doesn’t have an npm library to help make it easier on Jenkins.
Thanks for that reminder. I saw the Binomial talk and their ultimate goal is to have the Basis decoder be implemented in GPU hardware instead of code, which would make that the clear winner, but you’re right that the current implementation is (I believe) that Basis transcodes into DTX, ASTC, etc based on the device, so it essentially works the same as Babylon’s check for associated extensions. Except that Basis then unpacks into that format on the fly so you only need one file. I think it’s better to pre-compress the textures as KTX files for now, but I haven’t done any benchmark tests to confirm that.
But it is 100% worth the time to use compressed textures over PNG and JPG files
Quick update here, I tried with KTX (DTX) compressed texture. And I don’t see much improvement after everything is loaded vs a .png file.
That said the biggest improvement came from using power of two texture actually, as it was required for the compressed texture I then did the same for the png file. And it improves drastically the perfs.
Note that a Crunch compressed DXT1 file is even smaller than a JPG file. But look especially at the GPU memory footprint.
I once had to write this up so here was my explanation:
A square 4k image that’s 32-bit (8 bit per channel, RGBA) will use:
4096 * 4096 = 16,777,216 pixels
8 bits per channel * 4 channels = 32 bit = 4 bytes
4 * 16,777,216 = 67,108,864 bytes = 64 megabytes
And it needs to exist both on the GPU and in main memory.
A KTX file will be 64 bits per 4x4 pixels. (1024 * 1024) * 64 = 8.3 megabytes This also only exists in GPU
