Is PVRTexLib thread-safe?

This topic contains 13 replies, has 5 voices, and was last updated by  MChiz 6 years, 9 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #30213

    3DGamer
    Member

    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?

    #34128

    Gordon
    Moderator

    Unfortunately, PVRTexLib is not currently thread safe. This may be fixed in a future release.

    #34129

    3DGamer
    Member

    OK, thank you Smile

    #34130

    Pierre
    Member

    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.

    #34131

    Gordon
    Moderator

    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.

    #34132

    Pierre
    Member

    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?

    #34133

    Gordon
    Moderator

    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.

    #34134

    MChiz
    Member

    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

    #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.
    #34136

    Pierre
    Member

    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.

    #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!

     

    Tobias
    #34138

    Pierre
    Member

    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.

    #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
    #34140

    MChiz
    Member

    Hi Tobias:

    Thanks a lot for the info. I’m looking forward for your new versions.

    Carlos

Viewing 14 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic.