2021 texture import optimizations

[Aras]

Heads up: we’ve been spending some time on optimizing texture import times. Textures typically take up majority of game assets, and usually people spend a lot of time staring at progress bars, waiting for them to import or compress. While there are things like Accelerator (née Cache Server) that can alleviate that pain, it still sounded like a good idea to invest some time in.

So! Here’s what we see in our tests, in 2021.1a7, compared to 2020.2a21. The timings below are on my PC (1st gen ThreadRipper CPU with 16 threads, SSD), importing or switching platforms on a test project with 2GB worth of various textures (400 textures from actual projects; a mix of regular textures, normal maps, lightmaps, sprites, skyboxes, mask maps etc.):

• Importing for PC platform: 141sec → 111sec (1.3x speedup, or “30 seconds saved”),
• Importing for Android platform (ETC compression mode): 720sec → 266sec (2.7x speedup, or “7 minutes saved”),
• Importing for Android platform (ASTC compression mode): 1568sec → 602sec (2.6x speedup, or “16 minutes saved”).

Some texture types get larger speedups in the non-compression part, e.g. lat-tong panoramic layout cubemaps are much faster to import than before, because we’ve optimized some heavy parts there.

Low-risk parts of the ETC optimizations (1.4x speedup) are being backported to 2020.2b13, 2020.1.15 and 2019.4.16) as we speak.

ASTC optimizations are somewhat more involved; we haven’t decided yet whether to backport them.

We have some more plans in how to improve texture import times further, but these are likely to be after 2021.1 version (2021.1 is in “code freeze, only stability fixes” stage already).

Hope that helps, and you all can spend less time waiting for progress bars to finish!

[Peter77]

That’s fantastic news. Improving texture import performance is indeed a very necessary area. Thank you!

[JesOb]

Thanks a lot
Please think hard to backport ASTC optimisations to 2020.2 or 2020.3 at least, so we dont need to wait for it another 1.5 years

And work more on it. Accelerator is good idea but it often dont work, Unity can stall on trying to get textures from Accelerator for 15-30 minutes while just import them took about 30 seconds. Very often Accelerator just return wrong cached asset and ruin work at all. So it still not very usable in real prodaction projects even for personal use on one PC.

Thats way Thank You Very Much for your efforts

[Lars-Steenhoff]

Nice progress, this in combination with background compression, no more editor blocking, is going to help smooth out the workflow.
Thanks for the optimisation work!

[mahdi_jeddi]

Really happy to hear this.
We have a gigantic 2D project we sent for Case 1280527 with tens of thousands of sprites and atlases. You could use that as the ultimate benchmark But it needs more than 100GB disk space just to import!

[Aras]

Small update in 2021.1a8: mobile PVRTC compression is about 8% faster.

[mahdi_jeddi]

By the way, I checked again: the sprite atlas packing is insanely faster in newer versions compared to older ones (2020.1?, right now I’m on 2020.2.0b14). I don’t know if this was a bug that got fixed or an actual optimization in packing or just result of more higher level asset pipeline improvements like caching the older results.

[Neonlyte]

@Aras

Small update in 2021.1a8: mobile PVRTC compression is about 8% faster.

I’ll take that. It’s been very slow to compress iOS texture at best quality. Any improvement is a big plus.

Context: my project contains nearly 100 1024*1024 images that are displayed as UI graphics (specifically music album jackets). Because my UI displays the jackets in big sizes and because iPads have high resolution screens, I wanted to keep the visual fidelity so I used Best quality setting.

[Aras]

@Neonlyte

I’ll take that. It’s been very slow to compress iOS texture

Realistically though, you could switch to ETC2 (supported since A7 chips - year 2013) or ASTC (supported since A8 chips - year 2014) formats. Yes Unity today makes that a bit hard to do, since you have to either write an asset postprocessor script to assign that format automatically on iOS, or do that manually for all your textures. I think mobile team is looking at switching iOS default format to ASTC soon.

[AcidArrow]

@Aras

I think mobile team is looking at switching iOS default format to ASTC soon.

Can you make default format switchable by users so we don’t have to wait for Unity teams to switch them a few years later than when we need the switch to happen?

[Neonlyte]

@Aras

I think mobile team is looking at switching iOS default format to ASTC soon.

Isn’t iPhone 5s not supporting ASTC, but can still be updated to iOS 12? I don’t think Apple gives a way to exclude devices by texture support like Google Play does, and I don’t think the team is going to bump the min iOS version supported by Unity to 13, yes?

Good suggestions on ETC2 texture, though. I’ll take a look at that.

Append:
I tried to use ETC2 on some of my images. ETC2’s visual quality is actually quite a bit(lol) better than PVRTC at best quality settings. But the I remembered that I’m still supporting OpenGL ES 2.0.

Though, I’m dropping OpenGL for iOS soon by going straight to iOS 11 so ETC2 will come in handy.

[AcidArrow]

@Neonlyte

Isn’t iPhone 5s not supporting ASTC, but can still be updated to iOS 12?

No. You’re thinking of the iPhone 5C, which goes up to iOS 10. 5S supports metal / ASTC just fine. (EDIT: Maybe not… let me check again)

If you want to be able to make 64bit only, Metal only builds for iOS, requiring iOS 11 and up works fine and isn’t unreasonable. (EDIT: Again, maybe I’m wrong)

EDIT: I was right about 64bit & metal, but I missed that ASTC specifically needed another generation, so you’re right.

[Aras]

Some updates:

• In 2021.2 we’ll very likely have a new BC7 format texture compressor that is 2x-3x faster than the current one, at about the same image quality. BC7 is what’s used on PC/Consoles if you pick ‘high quality’ compression import setting. There will be an option to use the old one if someone absolutely needs it.
• We’re thinking about having some sort of “global, per user” max texture size & compression mode texture override setting, for cases where one does not care about textures that much. I’ve created a separate thread about this here under graphics section – feedback welcome!

[KamilCSPS]

@Aras

Some updates:

• In 2021.2 we’ll very likely have a new BC7 format texture compressor that is 2x-3x faster than the current one, at about the same image quality. BC7 is what’s used on PC/Consoles if you pick ‘high quality’ compression import setting. There will be an option to use the old one if someone absolutely needs it.
• We’re thinking about having some sort of “global, per user” max texture size & compression mode texture override setting, for cases where one does not care about textures that much. I’ve created a separate thread about this here under graphics section – feedback welcome!

Apologies if it’s a stupid question, but can BC7 compression be implemented for WebGL as well? Cursory research on the topic appears to point towards BC7 being technically supported. If so, then this feature sprint might help expand the WebGL platform a bit more.

Thank you

[Aras]

@KamilCSPS

can BC7 compression be implemented for WebGL as well? Cursory research on the topic appears to point towards BC7 being technically supported

I know nothing about WebGL, IIRC at least a few years ago none of the DX10+ desktop texture formats (BC4, BC5, BC6H, BC7) were exposed there. If they are exposed today, then yeah, if our WebGL folks would implement support in Unity then that would work. I’ll ask them.

According to https://developer.mozilla.org/en-US/docs/Web/API/EXT_texture_compression_bptc browser support table though, BC7 would only work in Firefox, and none of the other browsers?

[KamilCSPS]

@Aras

I know nothing about WebGL, IIRC at least a few years ago none of the DX10+ desktop texture formats (BC4, BC5, BC6H, BC7) were exposed there. If they are exposed today, then yeah, if our WebGL folks would implement support in Unity then that would work. I’ll ask them.

According to https://developer.mozilla.org/en-US/docs/Web/API/EXT_texture_compression_bptc browser support table though, BC7 would only work in Firefox, and none of the other browsers?

You are right. Saw it in the WebGL specs, saw it implemented in Firefox but completely missed its implementation in Chrome/Edge. Ugh.

Again, thanks for taking the time.

[castor76]

I wonder (if it is not already) worth investing into multi thread importing such as how shader compilation work now? I can see that multiple shader compiler kicks off to handle shader compile, so why not texture importing?

[Aras]

@castor76

I wonder (if it is not already) worth investing into multi thread importing such as how shader compilation work now? I can see that multiple shader compiler kicks off to handle shader compile, so why not texture importing?

“Yes and no” and “it’s complicated”.

So, within importing of a single texture, the importer tries to use as many cores as it can, where it can. E.g. texture compression is multi-threaded, as well as some other operations that happen during import.

Today Unity can not import multiple separate assets in parallel. That is being worked on (and not specifically for textures, but rather “in general”), but I don’t know when that will be done.

Shader compilation is different – during import it’s still the same (shader importing happens one shader at a time). Game data builds and other places that lead to shader compilation do go in parallel, very much like e.g. texture compression goes in parallel. But it’s still overall “one asset at once” today.

[castor76]

Thanks for the insight. I guess having more cores in CPU will help in today’s development process.

[ImpossibleRobert]

What is this sorcery? I just upgraded my project from 2019.4 to 2021.1.3. My library import used to take around 14 hours. It just finished after 2.5 now.

That. Is. HUGE!

Thanks a lot for putting in all this effort.