Is it possible to execute multiple CompressPVR() and DecompressPVR() in parallel? It seems like some parts of an other image compressed parallel get copied into the current one, very strange. Also, if let my program execute all CompressPVR() and DecompressPVR() one after another, everything seems alright. Is this my fault or is PVRTexLib not thread-safe?
Unfortunately, PVRTexLib is not currently thread safe. This may be fixed in a future release.
OK, thank you
I would like to follow up on this.
Today I spend quite some time getting our tool chain to be multithreaded just to find out that the PVR conversion is not thread safe (images will look very odd).
It would be very nice if someone from the PVR team could work on getting it thread safe. There sure must be a easy way to get this done.
Furthermore, I noticed the decompression from PVR4 on the mac simulator (I assume it can not display it natively) is very fast. Yet if I do a manual decompression on PC, it is very slow.
How is this possible? Is Apple using a custom lib?
Best regards,
Pierre.
Work is currently being carried out to improve the thread safety of PVRTexLib and this should be available for a future release.
We have faster decompression code that we’re testing currently and this should be available in the future as well.
Thank you Gordon. I thought no one would answer me.
Instead of running it in threads, I am now using CreateProcess to create a child procress. While this seems to improve the error rate, it still is broken.
I am not expert of how DLLs work, but it seems to be some sort of shared memory which causes this conflict.
Anyways, I am really looking forward to thread safety.
Regarding the new SDK and the “Engine”. There are mentions of reduced singletons. Does this relate to the PVR compression code?
I can’t vouch for PVRTexLib being thread safe at the moment, but the work to remove singletons was part of the work that needed to be done for this (obviously, having singletons around doesn’t help with multi-threading and keeping memory separated per thread…).
Hopefully, we should be able to commit more resources to the project (and to the PVREngine) so that the work will progress for the next release and thread safety is certainly something that we’d like to achieve.
Hi all!
Sorry for resurrecting this old thread but I’m currently very interested in the safe thread aspect of the library. It would make our asset pipeline considerably faster.
Are there any news about it? I have been looking around but I can’t find anything about the subject.
Thanks a lot,
Carlos
Hi Carlos,
Whilst most of the library should now be thread safe, and our fast, medium quality compressor is multi-threaded; the high quality compressor is not.
One option available is to have multiple instances of PVRTexToolCL running simultaneously, as this avoids threading issues, although this may be impractical depending on your pipeline.
Multi-threading is a change we are working on, but it is unlikely to make the next release.
Thanks,
Tobias.
Tobias, this is some interesting piece of information. I was unaware the medium quality setting was thread safe. It might actually be worthwhile (for me) to go about using medium setting with threads for development and HQ for release.
But I must first see how much worse the quality is. Maybe it is not good enough to work with.
Hi, Sorry I should probably clarify - although the code for the fast compressor is thread safe, PVRTexLib isn’t thread safe in the current release.
Despite PVRTexLib not being thread safe, the medium quality compressor is much faster than the high quality compressor. For this reason I would still suggest using medium quality during development, and high quality for deployment.
Our next (i.e. 2.8) release will be thread safe for medium quality compression, as the singletons will have been removed from PVRTexLib.
Apologies for any confusion!
Tobias
Thank you for clearing this up.
Now regarding this 2.8 release, how can I automatically be notified of new version?
I would be very handy be able to sign up for something like this. I plain text mail “new version 2.8” has been released would be totally sufficient.
Hi Pierre,
That's a good suggestion and we'll look into it. However as we've always done we will be posting an announcement in the SDK forum when it is released.
Thanks,
Tobias
Hi Tobias:
Thanks a lot for the info. I’m looking forward for your new versions.
Carlos
