-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Import: Cleanup and optimize etcpak compression method #47917
Import: Cleanup and optimize etcpak compression method #47917
Conversation
c53c789
to
b269c9d
Compare
512426a
to
3a603b4
Compare
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.
I wanted to restore etc 1 and 2 decompression but that is another pr. Looks good from a textual review. I think g4 android doesn’t work.
3a603b4
to
15acd5e
Compare
67d4dea
to
b58795d
Compare
_compress_etcpak
, clarify squish only for decompress
26f0fc8
to
793d70d
Compare
_compress_etcpak
, clarify squish only for decompressc3b55d3
to
591762f
Compare
591762f
to
95b6337
Compare
I went back to a safer approach closer to the original code (each mip gets written to a temporary buffer and Doing so I found that I was mixing metrics of the base and dest images which could have explained the crash I was getting with the old method. I might poke at it further but in the meantime this version should be somewhat safer. It imports all textures from the TPS demo fine. |
2720593
to
aee76ed
Compare
aee76ed
to
1bedf34
Compare
In the end I managed to find a way to avoid the temporary buffers. As in the original code, we |
Tested before/after with an optimized build to ensure that this PR actually helps or doesn't reduce performance. Importing all
So it seems I'm actually losing some performance here, surprisingly. I'll have to look into it further. |
1bedf34
to
8ee1574
Compare
Avoid unnecessary allocation of temporary buffers for each mip, and creates only one Image with the compressed data. Also renames variable and reorders code for clarity. Clarify that squish is now only used for decompression. Documented which formats can be decompressed in Image.
8ee1574
to
0ab928e
Compare
Cleaned up further with advice from @reduz so we no longer need to create an intermediate With these changes, I get the same performance before this PR and after on my hardware (~49-50 s). Hard to say if there's an actual speed gain as numbers fluctuate significantly depending on the start CPU load and heat on my laptop. For the reference, to test I do:
|
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 best test is that you said it imports tps correctly.
Avoid unnecessary allocation of temporary buffers for each mip, and redundant
Image
create
where we can assign the pointer directly.Also renames variable and reorders code for clarity.
Clarify that squish is now only used for decompression.
Documented which formats can be decompressed in Image.
Follow-up to #47370.
Notes
Lossy quality
etcpak doesn't provide any options for configuring the quality. Reading the upstream README, it says:
i.e. it's not geared towards perfect quality, but then that's also aligned with our default lossy import with quality 0.7. That means that if some users eventually want higher quality, we might need to provide another way to encode their assets (possibly via a thirdparty plugin).
But it also states:
And the image comparison does look fairly good to my untrained eye.
So now that we import ETC/ETC2 and S3TC through an importer that has no configurable quality settings, maybe we should consider removing the
lossy_quality
option?The PVRTC importer we use also doesn't handle
lossy_quality
, so only cvtt handles it for BPTC.Decompression
etcpak does provide support for decode ETC, ETC2, DXT1, and DXT5.
It's not part of the minimal
Process*
code we extracted from the library, but part of theBlockData.cpp
which depends on etcpak's own Bitmap representation and everything else: task scheduler, modified libpng, etc.https://github.com/wolfpld/etcpak/blob/1dc7b300453ae3d20cc43d906c89bcfcd8854cd3/BlockData.cpp#L694-L711
We could likely extract only the relevant
Decode*Part
methods and hook them with our ownImage
bitmap representation: https://github.com/wolfpld/etcpak/blob/1dc7b300453ae3d20cc43d906c89bcfcd8854cd3/BlockData.cpp#L723-L857That would require either some copy-paste work which makes it harder to sync with upstream, or splitting the upstream
BlockData.cpp
into two files (one part with only the byte decoding, and another part with the higher level Bitmap stuff) and have them agree to merge it.That would allow use to drop Squish (used to decode DXT) and add decoding support for ETC1/ETC2.