Commit Graph

3 Commits

Author SHA1 Message Date
f5eaf67e34 Atomics: Add 16 bit fetch + AND and fetch + OR signed integer operations
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.
2020-12-04 18:28:46 +01:00
4a179e8e3e Atomics: Fix missing 64bit implementation for 32bit platforms
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.
2020-11-25 12:43:43 +01:00
72a199e148 Atomic: Cover with unit tests
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
2020-11-19 17:19:48 +01:00