-
-
Notifications
You must be signed in to change notification settings - Fork 22k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize .hdr loading and RGB9E5 conversion #95291
Conversation
2b378ff
to
fd6ed9d
Compare
Can you post your samples as png / openexr converted from the your test cases to compare? |
Here are the samples in .exr format: hdrsamples.zip I'll upload png comparisons later. |
Image sources: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks great and the performance improvements are very exciting. I assume most of the performance benefit comes from not reading 8 bits at a time?
fd6ed9d
to
2845bbf
Compare
2845bbf
to
80cf6cb
Compare
Interestingly, the RGBE conversion makes the biggest difference. The fast low-range optimization had the biggest impact on load speeds. |
Wow, that is really surprising! But I guess it is more than just a few extra instructions, the old path moves data around a lot more too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, it works as expected. The imported HDR panoramas look pretty much identical to before (I can't tell a difference with ACES tonemapping and whitepoint set to 6 in Forward+).
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 40)
Using an optimized editor build (optimize=speed lto=full
). .godot/
folder is removed between each iteration.
Here's the time taken to open the editor, import the 4 HDRIs linked in OP with lossless compression and exit the editor. The times shown here include editor startup and shutdown, so the import process is actually more than 1.45× faster compared to before (probably at least 3× faster in practice).
Benchmark 1: bin/godot.linuxbsd.editor.x86_64.master ~/Documents/Godot/test_hdri_import/project.godot --import
Time (mean ± σ): 7.856 s ± 0.402 s [User: 11.515 s, System: 1.181 s]
Range (min … max): 7.326 s … 8.333 s 10 runs
Benchmark 2: bin/godot.linuxbsd.editor.x86_64 ~/Documents/Godot/test_hdri_import/project.godot --import
Time (mean ± σ): 5.399 s ± 0.203 s [User: 5.504 s, System: 1.076 s]
Range (min … max): 5.121 s … 5.698 s 10 runs
Summary
bin/godot.linuxbsd.editor.x86_64 ~/Documents/Godot/test_hdri_import/project.godot --import ran
1.45 ± 0.09 times faster than bin/godot.linuxbsd.editor.x86_64.master ~/Documents/Godot/test_hdri_import/project.godot --import
Stripped binary size is 8 KB smaller with this PR compared to master
.
Thanks! |
Improves .hdr file loading/importing times by doing the following:
Results:
Optimized x64 build
OS: Windows 10 64-bit
CPU: AMD Ryzen 9 5900X 12-Core
RAM: 64 GB DDR4
Loading only:
On average, this PR loads data ~25x faster.
Whole import:
On average, the import time for images with mipmaps is ~3.5x faster. Without mipmaps, it is ~4x faster.
The engine also generates mipmaps, saves the data to the import directory and reloads it again, which is bottlenecked by the disk's read/write speeds (The project was on an HDD).
TODO: