https://github.com/OpenImageIO/oiio/pull/273
I would very much appreciate if people could grab the code from this pull
request, and run:
build/ARCH/libOpenImageIO/atomic_test
build/ARCH/libOpenImageIO/spinlock_test
and report the timings after a fresh compile with USE_TBB ON, and again with
USE_TBB OFF. (On Linux and OSX, if you prefer running from 'make', then just
run 'make nuke ; make USE_TBB=1' or 'make nuke ; make USE_TBB=0'. On Windows,
or if you prefer otherwise, just set the CMake variable USE_TBB to ON or OFF,
respectively.)
I'm especially keen to hear the results from people on Windows, as that is the
major platform that I have no way to test myself.
If this makes it appear that there is no speed penalty from falling back on the
gcc & win32 intrinsics, compared to TBB, then I think we should simplify our
lives by removing TBB use entirely from OIIO.
On Apr 3, 2012, at 10:20 AM, Larry Gritz wrote:
> I had no idea Debian supported to many architectures!
>
> Hmmm... it seems that most of these failures are due to lack of TBB support
> for those architectures. TBB is optional for us; we really only need it
> for the implementation of atomic_int and atomic_long, and we have fallbacks
> for gcc. Could you try again, setting the CMake variable USE_TBB to OFF?
>
> Some have argued that we should simply excise TBB and use only gcc/win32
> intrinsics for our atomics. I think the only reason we haven't done this is
> worries about performance (especially on Windows), but I will prepare a test
> and post about that separately. If there's no performance penalty, maybe
> it's time to be done with TBB.
>
> -- lg
>
>
> On Apr 3, 2012, at 6:04 AM, Matteo F. Vescovi wrote:
>
>> Hi!
>>
>> Since the beginning of April, I'm maintaining OpenImageIO in Debian.
>> My main goal for this packaging is to provide Cycles Render Engine support
>> in Blender and it needs OpenImageIO for it.
>>
>> As you can see at [1], it fails to build on 12 of 14 architectures we have
>> in Debian.
>> I'd like to know if it's possible to fix this issue upstream instead of
>> patching this on Debian packaging (and I must admit that actually I've not
>> found a solution yet).
>> A full build log of a failing Debian GNU/kFreeBSD64 can be found at [2].
>>
>> Let me know if I can help in some ways, maybe preparing testing-purpose
>> builds in not-i386/amd64 architectures.
>>
>> Cheers!
>>
>>
>> [1] https://buildd.debian.org/status/package.php?p=openimageio
>> [2]
>> http://debomatic-kbsd64.debian.net/unstable/pool/openimageio_1.0.2+dfsg0-1/openimageio_1.0.2+dfsg0-1.buildlog
>>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
