- July 19, 2010 at 12:23 pm #30213
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?July 19, 2010 at 3:08 pm #34128
Unfortunately, PVRTexLib is not currently thread safe. This may be fixed in a future release.September 17, 2010 at 12:00 am #34130
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?
Pierre.September 28, 2010 at 5:13 pm #34131
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.September 29, 2010 at 8:34 pm #34132
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?September 30, 2010 at 10:26 am #34133
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.January 15, 2011 at 5:49 pm #34134
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,
CarlosJanuary 17, 2011 at 10:08 am #34135
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.January 17, 2011 at 10:16 am #34136
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.January 17, 2011 at 10:44 am #34137
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!TobiasJanuary 17, 2011 at 11:02 am #34138
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.January 17, 2011 at 2:18 pm #34139
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