Is used for platforms for which we do not have native implementation,
such as MIPS, for example.
It is possible to test locking implementation on local computer by
defining `ATOMIC_FORCE_USE_FALLBACK` in the atomic_ops_unix.h file.
Run full regression suit with the locking implementation on amd64
Linux platform and all tests passed.
Having non-optimal but working implementation for odd-ball platforms
seems to be a better choice than failing the build entirely.
Differential Revision: https://developer.blender.org/D12313
I could use a 16 bit atomic fetch + AND for D9719. The alternative would be to
turn a `short` into a `int` in DNA, which isn't a nice workaround.
Also adds tests for the new functions.
Blender uses 64bit atomics to manipulate SessionUUID, and these atomics
were not defined on any of 32bit platforms.
While official support is limited to 64bit platforms only, the code
should not make assumptions about bitness or endianess, in terms that
there should be codepaths and fallback (or provision of them) for 32bit
platforms.
This change makes 64bit atomic functions defined for all platforms.
The atomic_test was compiled and successfully tested on i686 and armv7l
platforms. The rest of compilation process of Blender will be very
tedious, so that was not done.
This change is essential, but not necessarily enough to make Blender
compilable on i686 (ability to compile Blender on 32bit platforms was
lost during the 2.91 development).
This is a functional part of original fix done by Brecht in D9577.
There is a special defines block needed for ARM on Linux. Move it from
public header to an implementation file.
No functional changes.
This is a non-functional part of original fix done by Brecht in D9577.
Cover all atomic functions with unit tests.
The tests are quite simple, nothing special so far. The goal is to:
- Make sure implementation exists.
- Implementation behaves the same way on all platforms
(We had issue when MSVC and GCC were behaving differently in the
past).
- Proper bitness is used for implementation and non-fixed-size
function implementation.
The tests can be extended further to make sure, for example, that
CAS operations do not cast arguments to a more narrow type for
comparison. Considering it a possible further improvement, as it is
better be done being focused on that specific task.
There is an annoying ifdef around 64bit implementation, which uses
same internal ifdef as the header does. This check is aimed to be
removed, so is easier to simply accept such duplication for now.
The tests seems somewhat duplicate for signed/unsigned variants and
things like this. The reason for that is to keep test code as simple
as possible: attempting to do something smart/tricky in the test code
often causes the test code to be a subject of being covered with its
own unit tests.
Differential Revision: https://developer.blender.org/D9590
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
While atomics library was trying to use "user-space" defined
LIKELY() and UNLIKELY(), this is not always true that user
code was checking for those macro coming from an unrelated
area.
This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming
Things to note:
1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it)
2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370)
victor_cpu
msvc:3099.51
clang:2796.43
pavillon_barcelona_cpu
msvc:1872.05
clang:1827.72
koro_cpu
msvc:1097.58
clang:1006.51
fishy_cat_cpu
msvc:815.37
clang:722.2
classroom_cpu
msvc:1705.39
clang:1575.43
bmw27_cpu
msvc:552.38
clang:561.53
barbershop_interior_cpu
msvc:2134.93
clang:1922.33
3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs.
4) X64 only currently, X86 builds but crashes on startup.
5) Tested with llvm/clang 6.0.0
6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration
7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc.
8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows.
9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3304
Reason is motsly that dealing with type conversion in calling code is
not great, makes it less readable, and can generate hidden bugs in case
original type changes and atomic primitive calls are not updated
accordingly...
While unlikely to have had any serious effects because of limited use, the
previous implementation was not actually atomic due to a data race and
incorrectly coded CAS loop. We also had duplicates of this code in a few
places, it's now been moved to a single location with all other atomic
operations.
The assembler version in Windows used to return the previous value
of the variable while all the other versions return the new value.
This is now fixed for consistency.
Note: this bug had no effect on blender because no part of the code
use the return value of these functions, but the future BGE DeckLink
module makes use of it to implement reference counter.
This commit:
* Removes most of all dirty internal details from public atomi_ops.h file, and move them into /intern private subdir.
* Removes unused 'architectures' (__apple__ and jemalloc).
* Split each implementation into its own file.
* Makes use of C99's limits.h system header to determine pointer and int size, instead of using fix hardcoded list of architectures.
* Introduces new 'faked' atomics ops for floats.
Note that we may add a lot more real and 'faked' atomic operations over integers and floats
(multiplication, division, bitshift, bitwise booleans, etc.), as needs arise.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1982
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_n are not defined on this architecture
for some reason, however those functions are available.
Adding a workaround for newly used __sync_fetch_and_and() function.
Needed by incomming changes in pbvh.c.
Note that we make it much simpler than for other primitives in this file - think
we could revise its content to make it simpler one day...
Sergey Sharybin
Heinrich Schuchardt
Julian Eisel
Harley Acheson
Dalai Felinto
Campbell Barton
Sergey Sharybin
Ray Molenkamp
Bastien Montagne
Mai Lavelle
Benoit Bolsee
Brecht Van Lommel
Matteo F. Vescovi
Brecht Van Lommel