PVRTexLib.dll always uses max threads for 1 texture

PowerVR Insider
1

When batch processing textures, PVRTC encoding use all available cores for a single texture. This results in cores ^ 2 threads in use. 16 textures need 16x16 256 threads. Can this library be modified to allow passing down a thread count (ideally 1)?

2

Hi alecazam123,

Thanks for your message. I’ll ask the Tools Team about your proposed changes and come back to you with the answer.

Best regards,
Alejandro

3

Hi alecazam123,

After reviewing with the Tools Team, I’m afraid currently there’s no way for the user to control the amount of threads used for compression for PVRTexTool/Lib. There’re plans to implement this feature at some point but not in the near future.

Bets regards,
Alejandro

4

This was swamping build servers, so we just dropped the PVRTC encode format. There are so many issues with this encoding format from square pow2 requirements, to wrap handling, to lack of open-source encoders.

5

Hi alecazam123,

Could it be possible to have a list of the issues you have come across regarding the PVRTC encode format? I’m sure Tools Team will be thankful to analyse and work on it.

So far, we’ve:

  1. Square pow2 requirements.
  2. Wrap handling (what would be here the issues?).
  3. Lack of open-source encoders.

Best regards,
Alejandro

6
  1. This is possibly fixed in PVRTC2 since it went to 4x4 blocks, but iOS and most platforms don’t support it. So unfixable for PVRTC1. ETC2 is supported, and ASTC/BC/ETC2 all support non-power2 non-square mips. And M1 now has BC support, so that’s why I’d encourage more encoder efforts there.
  2. PVRTC1 at least needs to be provided the wrap vs. clamp state for each texture edge to properly encode. This often is assumed wrap or assumed clamp. That’s not something other encoding formats need AFAIK.
  3. This has been an issue since the beginning of the PVRTC format, and PVRTexLib or Geldreich’s Basis seem to be the main encoders out there.
  4. The max processor count thread usage for the encoder swamps build servers that are trying to process 1 texture per processor. All other encoders allow thread count control except the PVRTexLib. Even cuttlefish and other encoder wrappers can’t avoid this.
7

Hi alecazam123,

Thank you so much for the detailed feedback, I will make sure every suggestion reaches the Tools Team.

Best regards,
Alejandro

8

Hi alecazam123,

I got a reply from the Tools Team regarding some parts of your feedback.

The power of two limitation is a PVRTC1 format limitation I’m afraid, present at hardware level. We’ve to take into account here that the format is about 20 years old. On the other side, PVRTC2 does not have that restriction.

For the max processor count thread usage, it is planned to address this limitation in a future release, but it has not yet been scheduled.

Best regards,
Alejandro

9

Well, we had a deadlock in the library and faced the same issue - lack of threading control.
If you’re interested I can probably share a patched DLL with you that will only spawn 1 extra thread :slight_smile:

10

Thanks Alex. I’ve already dropped PVRTC since we needed our build machine to complete in 3 minutes instead of 120 mins of thread contention. I’m using my own encoder/decoder and viewer now too for ETC2/BC/ASTC, but the new PVRTexToolGUI is a big improvement. I don’t want to go back to the limits of PVRTC1, and most of the tooling (f.e. Preview and Thumbnails on macOS) have dropped it as well.