My name is Matias N. Goldberg, I normally maintain the 2.x branch of Ogre aka ogre-next and I wrote Betsy, a GPU texture compressor that runs on GPUs.

This work was commissioned by Godot Engine through the Software Freedom Conservancy to solve a major complaint: importing textures is excruciantly slow and takes many minutes.

Certain compression algorithms such as BC1-5 are quite simple and there are already fast high quality compression algorithms.

However algorithms such as BC6, ETC1, ETC2 and EAC are currently taking the majority of time and thus considerably attention were given to these.

Nonetheless Betsy implemented compute-shader versions for BC1,3,4,5,6, ETC1,2 and EAC algorithms.

Betsy works as a standard Command Line tool which means it can be used like any other exe tool outside of Godot.

More importantly, Betsy was developed with integration to Godot in mind, which is why its code has been isolated and abstracted from API details, written in GLSL shaders since Godot uses Vulkan.

Godot can make further performance improvements a standard CLI tool can’t, because Godot doesn’t have to initialize the graphics API every time it is invoked to compress a texture; and Godot can upload a texture just once and then encode into multiple formats (e.g. compress into BC1 and ETC1, or EAC and BC4 at the same time); rather than re-upload the texture again for every format we need to compress into.

Theoretically the CLI tool could accept to encode many textures in a single invocation (e.g. encode A.png into A.etc1.ktx A.etc2.ktx A.bc1.ktx and B.etc1.ktx B.etc2.ktx B.bc1.ktx) but we were worried that could complicate the code and make its integration with Godot harder. Additionally it’s hard to write a generic tool interface that would take advantage of such command line syntax.

What is texture compression and why you care

GPUs have precious limited available RAM. Too many big textures and you can see yourself running out of RAM.

When that happens, the GPU driver may fallback to streaming from regular system RAM over the PCI-E bus.

When this works, a significant performance degradation can happen. When this doesn’t, the game will just crash.

On phones, lower RAM consumption isn’t the only reason. Smaller textures mean less bandwidth. And less bandwidth means better battery life (and sometimes less bandwidth can also mean higher performance on both desktop and mobile).

There are three major types of texture compression categories, but only one is useful for GPUs:

Lossless (e.g. PNG)

This compression family lower the size of the texture using algorithms such as gzip, bzip or LZMA, among others. The main advantage is that the bits of the original texture are preserved. That’s why it’s loss-less i.e. no quality is lost.

The disadvantage is that they take a variable time to decompress i.e. it can take anywhere as 1 nanosecond to 30 seconds, or who knows, maybe more.

Unfortunately, due to this variable-time in decompression, these family of texture compression algorithms are of no use for a GPU.

Another disadvantage is that the compression ratio is unknown. A 1024x1024 may compress to 10kb, while another 1024x1024 texture may compress to 0.7MB.

This large unknown disparity in size also makes them inviable for GPUs.

This means that a 1024x1024 RGBA PNG texture that is only 10kb on disk must be decompressed before uploading to the GPU, thus always occupying 4MB of video RAM.

Lossy (e.g. JPEG)

This compression family uses algorithms like Discrete Cosine Transform (aka DCT) to discard some details of the original image in order to hugely reduce their size.

That is: they do lose quality, but it is often hard to notice and achieve huge size reductions.

Unfortunately, they’re still a no-go for GPUs due to how expensive it is to decode DCT, and because decompressing often requires ‘postprocessing’ passes that looks on the whole texture to hide artifacts and improve quality.

Therefore, just like in the PNG case, a 1024x1024 RGB JPEG texture that is only 120kb on disk must be decompressed before uploading to the GPU, thus always occupying 4MB of video RAM.

GPU lossy (e.g. BC1-7, ETC1-2, EAC, PVRTC, ASTC)

We finally arrive at the family this article is about!

This family of compression algorithms meet two criterias that are key for GPUs:

1. Decompression is fast and easy, and can be done in constant O(1) time. i.e. it always takes the same amount of time. e.g. if it takes 20 nanoseconds on a given GPU, it always takes 20 nanoseconds, no matter which pixel you need to fetch.
2. Compression ratio is constant. For example BC1 has a 1:8 compression ratio. That means that a 1024x1024 RGB texture which on RAM would occupy 4MB uncompressed, using BC1 it will always occupy 0.5MB

To be clear: except rare occassions, these formats cannot compete in quality against the other family of lossy formats (like JPEG), and they do not intend to.

Fast decompression and reasonable quality are the goals here. If you don’t like it and have infinite money, you can always buy a 24GB RAM GPU.

But for the rest of us, this compression family is a good deal.

Why are there so many formats (BC1, BC4, ETC1, etc, etc) you ask?

Well, one reason is patents. For example ETC1, ETC2 and EAC appeared because phone vendors didn’t want to pay the patent for the BC1-5 family of compression algorithms. This patent expired on March 16, 2018. However plenty of phones came before 2018.

Another reason is that some algorithms are better suited for different content. For example BC5 & EAC are very good at compressing normal maps, while BC1 & ETC1 are reasonably good for compressing RGB photo-like textures, and BC3 and ETC2 are reasonably good for RGBA photo-like textures.

Then some formats simply are improvements over time: BC7 came much later and is BC1 on steroids. Although it is double the size of BC1, it preserves quality much better than BC1 ever did. If your card supports DirectX10, then it supports BC7. But if it’s older than that, it won’t.

Then there is the relatively-new ASTC which is a very good and flexible patent-free compression format, but desktop vendors resist it because it is very expensive in terms of HW manufacturing costs and die area size. Also not all phones support it, either because they’re too old, or due to costs.

GPU compression can take (a lot of) time

OK, so we just have to use those formats I mentioned above right? We use BC1, BC3, ETC1, etc.

Hold on! Not so fast:

Some GPUs support some textures but not others. While there are assumptions that can be made (e.g. all desktop DX10-class GPUs and newer support BC1-7), if you aim at different platforms (Windows, iOS, Android) the answer to the question ‘which format should we use?’ then the answer will be: All of them.

Games usually have to bundle the same textures in all suitable formats and pick the best supported variation based on the HW it is running.

This isn’t good for package sizes on disk, but we ensure compatibility. Some mobile games decide to download the texture pack after installation once it knows which device it is running on.

Other solutions like Basis Universal use the term ‘transcoding’ to generate an ETC1 or BC1 texture based on a single binary package. By trading off some quality and saving shared information, an ETC1 or BC1 texture can be generated on the fly.

The main problem is that some formats like BC1 are easy to encode. But other formats like ETC2 or BC7 can take a lot of time. Encoding a bunch of small textures can take literal minutes!

If an artist needs to wait 30 seconds to deploy to his phone every time he changes a few textures to see how it looks like, then we’ve got a big iteration problem!

That’s where betsy comes in.

Not all encoders are born equal

Performance isn’t the only metric! Another issue is that not all compressors produce the same quality!

There are many ways to encode a texture, and arriving to each solution will achieve slightly different results. Some compressors are better at preserving quality than others.

Betsy aims at encoding in high quality. Even if we may not end up being the best encoder, we can’t sacrifice quality for speed (unless it’s configurable and the user wants to)

Betsy is a GPU encoder

Regular code is written to be run on a CPU. Betsy runs on a GPU. GPUs are massively parallel machines. And GPU compression happens to parallelize quite well (some formats better than others)

What is faster depends on what CPU do you own vs what GPU do you own, and which compression format is selected. A 64-core Ryzen Threadripper paired with a GeForce 1030 or Radeon HD 7350, the CPU will obviously beat the GPU.

However if you own the latest GeForce 3080 or Radeon 6800 XT, chances are a GPU encoder will win in encoding time.

It is important to mention that my work was mostly porting existing codecs written in C or C++ for the CPU, and convert them into GPU-friendly compute shaders. A notable exception is ETC2’s P-mode which has been extended with our own efforts to significantly improve encoding quality of this mode.

You can find more information in the LICENSE and README pages.

Benchmark Performance

OK enough boring explanation! Let’s see how Betsy fares against other encoders:

Notes:

1. CPU is Intel i7 7700 3.6Ghz (4.2Ghz turbo). 2x16GB RAM 3000Mhz. 4 core, 8 threads.
2. GPU is AMD Radeon HD 560 2GB VRAM
3. Benchmark was done on Linux Ubuntu 18.04 LTS (HWE), Mesa 20.1.3
4. etc2comp is what Godot currently uses
5. ConvectionKernels aka CVTT, which uses SIMD/SSE to run compress multiple blocks at once, similarly to what Betsy does.
6. Multithreaded tests were done spawning one process for each texture. This is suboptimal as it results in oversubscription for CVTT, and excessive contention of access to GPU for Betsy. The exception is etc2comp which supports native per-texture multithreading out of the box.
7. Single threaded numbers for CVTT are included because multithreading is not supported out of the box by CVTT
8. Single threaded numbers for etc2comp are not included because it supports multithreading out of the box, and single threaded version is simply way too slow.
9. The original Kodim set’s resolution was too small to fully saturate the GPU in Betsy (according to radentop, around 60% GPU usage), which is why there is a strong difference between the ‘multithreaded’ and ‘singlethreaded’ versions. This difference gets much smaller for the 2048 upscaled set (keeping aspect ratio).
10. Betsy was run for every texture independently, which includes a small overhead for initializing OpenGL every time. This could be further improved to support encoding multiple textures with one single invocation.
11. Betsy’s first run in a system may take considerably larger time as compute shaders must be compiled and will later be cached by the driver in subsequent runs. This will happen again if the driver is updated.
12. All values are time in seconds.
13. Betsy’s Quality = 1 (medium quality) was included because it only affects ETC1 modes (not the extended T, H and P ETC2 modes), the quality difference is very low, but the performance gains are gigantic.
14. The scripts used to run this benchmark can be found on Github/betsy_benchmark

ETC1

ETC2 RGB

BC1

Notes:

1. This needs more research, but it appears BC1 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time
2. CVTT supports BC1, however its CLI tool doesn’t come with BC1 support out of the box and I had no time to add support for it to do the benchmark

BC5

Notes:

1. This needs more research, but it appears BC5 is bottleneck by GPU initialization, GPU uploads and data download, rather than encoding time
2. CVTT supports BC5, however its CLI tool doesn’t come with BC5 support out of the box and I had no time to add support for it to do the benchmark

Benchmark quality

Notes:

1. RSMLE: Lower is better. It means Root Mean Squared Logarithmic Error.
2. Betsy q = 1 is medium quality
3. Betsy q = 2 is maximum quality
4. It is unknown why ConvectionKernels some RSMLE increased in ETC2 over ETC1. It could be a CVTT bug, or a difference in how CVTT measures error vs how I measured it.

ETC1 RGB

ETC2 RGB

BC1

BC5

Get Technical

If you’re a GPU nerd, we have an in-depth analysis of how betsy’s compute shaders are implemented.

Keep in mind it is quite advanced and assumes you’re somewhat familiar with GPU shader coding.