Yeah, but I can't say I thought of that as much of a bonus since, if anything, for a while it meant you had to use TBB too to avoid some issues or a complete flattening of the threading, and the intel suit of tools isn't exactly cheap for home work :)
My point for mentioning Maya though isn't that it's the shining beacon of progress, but that while limited it was available early enough (2008? 2009?) that at least you could have some implementation done without catastrophic results and start future proofing, and it was progressed from there to actually better than minimal over the following releases, to the point now it's enough to at least provide infrastructure if you decide to roll your own. It's also enough that if you're patient and adventurous you can sort of trick some allegedly non thread-safe parts of it to be usable, at least to the point of speeding up copies (IE: wake up rawP and rawN for a copy instead of having to copy once and then copy to device again). I'd expect it to be reasonable enough to go down the same path for Soft, starting from a minimum of safety for the main thread, and moving on to offering basic facilities (persistent pool and lock monitors) before it bothers with all the fancier things that, once you're safe, you can always patiently enough squeeze out of boost or C++11 threads (assuming the world wakes up to it). After all it's the kind of improvements normally facing users who'd understand the need and constraints of a slow trickle kind of implementation, it's not the kind of thing you have to do all or nothing before you can offer them. On Wed, Jul 24, 2013 at 6:04 PM, Serguei Kalentchouk < serguei.kalentch...@gmail.com> wrote: > It's worth mentioning that Maya has been using Intel's Threading Building > Blocks library internally in addition to OpenMP. > Although it's not directly exposed through their API you could use the > library directly to write threaded code. > Unfortunately the vast majority of Maya API methods are still not > thread-safe and thread safety is not documented. > > So yeah I would definitely second the need for improved threading support > across both applications. > > P.S. at least Maya has finally moved away from VS v90 platform, now it's > only a couple of years behind... > > > > On Tue, Jul 23, 2013 at 11:49 PM, Raffaele Fragapane < > raffsxsil...@googlemail.com> wrote: > >> Thanks for responding Chris. >> >> Well, for most of the old school ones (apps) it'd be an impossible amount >> of work to make it truly pervasive, but to be honest given the domain of >> cheap-shot parallelism in apps like Soft or Maya just making thread safe >> (or offering mechanisms to find thread safe implementation boundaries) a >> small portion of some accessors and various update functions would be a >> huge leap forward. Documentation too. >> >> It's not a huge deal for the CUDA side of work since most of the time I >> one works in the interval between host2device copy and device2host >> copyback, the boundaries tend to be forced anyway, but the moment you don't >> have CUDA and Titan speed memory in the picture (anything that needs to run >> on a farm in example :) ), copying entire chunks of the geo data is rather >> wasteful, not to mention slow, and the lack of native facilities for >> pooling of any kind makes it hard to scale the threading meaningfully. >> >> Maya doesn't exactly do well across the board in those regards, but at >> least with openMP, and this is a few years ago now, they added a mainthread >> safe way to maintain a pool, and then slowly inched from there to sucking a >> fair bit less . In Soft I still haven't quite found a way to not have a >> crippling overhead. >> Even a simple addition ala openMP, just to have a live pool, a couple >> lock options, and basic wake-from-lazy to use raw references to geo would >> go a very long way. >> >> It'd be nice if you guys would consider at least that much in the >> roadmap, even if only as a "use at your own risk" and basic implementation. >> >> ICE is great and all, but it's not ALWAYS a viable option, and it tends >> to cut off a good chunk of libraries and facilities that simply don't play >> well in context. >> Supporting compilers younger than a decade (and this holds true for Maya >> too) would also be nice :) >> >> >> >> On Wed, Jul 24, 2013 at 3:56 PM, Chris Chia <chris.c...@autodesk.com>wrote: >> >>> I have yet heard any update on this. >>> And I believe this would involve a lot of work for many DCCs. >>> >>> >>> >>> >>> >> >> >> -- >> Our users will know fear and cower before our software! Ship it! Ship it >> and let them flee like the dogs they are! >> > > > > -- > Technical Director @ DreamWorks Animation > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
