Add Betsy to speed up BC6 compression

[BlueCube3310]

Excerpt of #91150.
Fixes #80456.

Implements the Betsy GPU texture compressor to drastically speed up BC6 compression, which will be essential for compressing baked lightmaps.

Performance (compression ONLY):
Build - Production 64 bit,
CPU - Ryzen 9 5900x,
GPU - RTX 4060 TI

image	CVTT	Betsy
Symmetrical garden 8k .hdr with mipmaps	92.4s	475ms
Cobblestone Street Night .hdr 4k with mipmaps	26.5s	217ms
Laufenurg Church 8k .hdr with mipmaps	99.3s	440ms
Little Paris 8k .hdr with mipmaps	92.7s	467ms

TODO:

• optimize the setup (shader compilation, RGB->RGBA conversion), since that takes up most of the time,

TODO after merging:

• move the optimized functions to Image (Optimize image conversion for half and float formats. #92291 and Image: Add a method for detecting signed values #92799),
• Optimize .hdr file loading (Optimize .hdr loading and RGB9E5 conversion #95291),
• implement signed compression support (or at least try to),
• fix layered texture import when compressing layers with different signs,
• look into optimizing CVTT to be a viable fallback.
• parallelize mipmap compression (idea: pack all mips into a second image with half the width and the same height as the original and run in parallel).

[clayjohn]

This is going to help immensely with our lightmapper! Currently the lightmapper doesn't compress the results since it is so slow. But with this, we can finally re-enable compression by default

[BlueCube3310]

In terms of performance, a layered 4096x2048x8 image takes ~11 seconds to import on an RTX 4060TI.

Update: After optimizing RGB-RGBA conversion and disabling the forced auto mipmap generation for layered textures (is there any reason why it was enabled in the first place?), the compression time goes down to ~7 seconds, and that's still mostly CPU bound. I'm hoping to bring it down to around 2, 3 seconds.

[BlueCube3310]

Signed compression is now supported, though because the sign detection happens on individual layers, directional lightmaps break when recombined. The same issue happens in master.

[fire]

Is there a way of bc6 using sign detection on individual layers or the entire set at once without too much research time?

This seems like we need to implement a batch system?

[BlueCube3310]

This is tricky since each layer is compressed as an independent image, and as such one layer isn't aware of the other ones. IMO the layered/3d/cube texture import pipeline needs a light rework as the current approach also causes other problems due to this issue.

[BlueCube3310]

Did some benchmarks, the difference in performance is incredible (up to 200 times faster on some large images).

[Calinou]

Tested locally, it works as expected.

Benchmark

PC specifications

• CPU: Intel Core i9-13900K
• GPU: NVIDIA GeForce RTX 4090
• RAM: 64 GB (2×32 GB DDR5-5800 C30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 39)

Using a Linux optimized (optimize=speed lto=full) editor build.

image	CVTT	Betsy
French graden 8k with mipmaps	52.3s	4.2s
German town at night 4k with mipmaps	14.1s	1.1s
Church at starry night 8k with mipmaps	56.7s	4.1s

This is on average a speedup of 13.1×.

It's strange how my import speeds are quite a bit slower than @BlueCube3310's though, considering my GPU is significantly faster. I measured the times by starting the editor with --verbose, which prints the time taken after every reimport. The texture was assigned to a StandardMaterial3D so it was detected as used in 3D, which enables VRAM compression and mipmaps.

Output quality seems pretty much identical – I can't spot any differences.

Impact on stripped binary size:

115,089,512  godot.linuxbsd.editor.x86_64
115,118,184  godot.linuxbsd.editor.x86_64.betsy-bc6h

This is only 30 KB and only affects editor builds, so it's pretty reasonable.

Great work 🙂

PS: hdri-haven.com is a typosquatting site, use hdrihaven.com (which redirects to polyhaven.com) instead.

[BlueCube3310]

It's strange how my import speeds are quite a bit slower than @BlueCube3310's though, considering my GPU is significantly faster.

My results only contain the time it takes to execute the compress function, and not the whole import process (decoding, mipmap generation, etc.). On my machine the whole process took ~14s with Betsy.

Edit: Both CVTT and Betsy now print the compression time with verbose.

PS: hdri-haven.com is a typosquatting site, use hdrihaven.com (which redirects to polyhaven.com) instead.

Redirected the sources to polyhaven.

[fire]

I was thinking about fix signed compression (when importing a layered texture, some slices are signed and others aren't, so the combined texture breaks). can we disable the signed path or somehow resolve or do we have to implement batched signing properly?

[BlueCube3310]

I got signed compression to (kind of) work:

(The image is multiplied by -1 in the shader)

This can be done by running the SignExtend function on the endpoints, though it only works somewhat correctly with the low-quality mode. The quality mode has similar artifacts to CVTT.

Low-quality mode works well, unless the source image has a large difference between the color channels:

It looks like in order to work properly, the signed mode needs to utilize all 14 block modes, while Betsy only supports 3.

[BlueCube3310]

After #95291 and #92291, the import times as a whole have gone down significantly. It takes ~4.5s and ~1.2s respectively to import an 8k and 4k HDRi on a debug build.

[fire]

Is this ready for merge? What is left?

[BlueCube3310]

I'd say it's ready, the only thing I'm worried about is that it will cause crashes on devices that don't fully support compute shaders (like mobile), similarily to the lightmapper. I don't think there's currently a way to verify that, but if there is it should be made to fall back to CVTT.

[Saul2022]

,similarily to the lightmapper.

For lightmap it kind of ok since android does not support baking lightmap atm.

[BlueCube3310]

Apparently some mobile devices support compute shaders, but I'm still worried that we might run into an edge case with some older models that will cause the output texture to be corrupted/empty. Worst case scenario, said device only supports ASTC natively and the user will export the project with broken textures to desktop platforms.
I'm conflicted whether to disable betsy on mobile altogether, or leave it in for now and see the results of wider testing.

[Saul2022]

I'm conflicted whether to disable betsy on mobile altogether, or leave it in for now and see the results of wider testing.

Prob make it a warning on the mobile device unable to handle compute shaders which means betsy not being supported. Eitherway most mobile devices can’t handle mobile backend due to vulkan drivers being broken there, as for compatibility renderer it might have to be automatically dissabled and can be enabled back for mobile devices that can handle it .

[BlueCube3310]

After some consideration, I've disabled it for mobile since there is currently no easy way (that I know of) to check for whether a specific device has working compute support. Also, the engine can now be safely built without betsy (previously it would fail the compression if the module was missing, now it will fall back to the default compressor).

That should hopefully be the final bug fix, I think this is ready to merge now.

[clayjohn]

After some consideration, I've disabled it for mobile since there is currently no easy way (that I know of) to check for whether a specific device has working compute support. Also, the engine can now be safely built without betsy (previously it would fail the compression if the module was missing, now it will fall back to the default compressor).

That should hopefully be the final bug fix, I think this is ready to merge now.

Any device that supports Vulkan supports compute shaders. So if you are able to create a RenderingDevice, you can assume that compute shaders are supported.

That being said, mobile devices themselves don't support reading from BC6 textures anyway.

What I would do is implement a fallback so if compressing fails, we still continue and try to compress using CVTT

[BlueCube3310]

Done as suggested, it should now work on mobile correctly.

[BlueCube3310]

Directional lightmaps update (not included in this PR):

After experimenting with several biasing strategies, I settled on one inspired by Frostbite's Flux, which involves storing the result of dividing L1 SH coefficients by L0, then biasing them to the 0.0-1.0 range. So far it seems to not be affected by artifacting:

In the future this may allow compressing L1 coefficients as LDR textures, which will reduce their size (if we compress them as BC1).

[jcostello]

@BlueCube3310 When ever you feel you have something solid, please open another PR so I can test the directional lightmap compression

[clayjohn]

Everything looks good to me! Thank you very much for moving this forward

[akien-mga]

Thanks!

[atirut-w]

Does this PR mean that HDR sky textures will import faster without having to touch the import settings by default?

[Calinou]

Does this PR mean that HDR sky textures will import faster without having to touch the import settings by default?

Yes, #95291 and #92291 also helps for HDRIs using Lossless compression (or VRAM Uncompressed).