Remap q5 to q8, q6 to q9, q7 to q10 and q8 to q11, and push
q4 to the stack.
This was missed previously since the codec unittest doesn't
test encoding with loop filter enabled yet.
This code checked whether one function pointer was non-null,
but the went on to call a different function pointer. Check
for the one that actually was called.
There's no requirement to work with the Intel NDK. The NDK build
files don't even need to create any cpufeatures subdirectory since
all of the cpufeatures library is handled within the normal build
system. Finally, the encoder makefile tried to create a directory
for "welsdecdemo", not anything for "welsencdemo".
Thus, if this really was necessary, it would already have been noticed
that it missed an entry for "welsencdemo". Therefore, remove this
hack/workaround.
According to the calling convention, the registers q4-q7 should be
preserved by functions. The caller (generated by the compiler) could
be using those registers anywhere for any intermediate data.
Functions that use more than 12 of the qX registers must push
the clobbered registers on the stack in order to be able to restore them
afterwards.
In functions that don't use all 16 registers, but clobber some of
the callee saved registers q4-q7, one or more of them are remapped
to reduce the number of registers that have to be saved/restored.
This incurs a very small (around 0.5%) slowdown in the decoder and
encoder.
According to the calling convention, the registers q4-q7 should be
preserved by functions. The caller (generated by the compiler) could
be using those registers anywhere for any intermediate data.
Functions that use 12 or less of the qX registers can avoid
violating the calling convention by simply using other registers instead
of the callee saved registers q4-q7.
This change only remaps the registers used within functions - therefore
this does not affect performance at all. E.g. in functions using
registers q0-q7, we now use q0-q3 and q8-q11 instead.
Now calling WelsThreadJoin is enough to finish and clean up
the thread on all platforms.
This unifies the thread cleanup code between windows and unix.
Now all of the threading code should use the exact same codepaths
between windows and unix.
Arm assembly has got two variants of the syntax, the old legacy
syntax, and the new modern UAL (unified assembly language) syntax.
Most arm assembly is the same in the both syntaxes, but some
uncommon cases change the order of suffixes - the "subscs"
instruction would be written "subcss" in the old syntax.
The apple tools default to UAL, while the GNU tools (e.g. in
android) require you to specify ".syntax unified" to enable the
new syntax. When enabling the new syntax with the GNU tools, some
cases of "sub r0, r1, lsl #1" needs to be written explicitly as
"sub r0, r0, r1, lsl #1", handled in the previous commit.
This allows using the same, modern syntax for things like subscs,
without needing to have two alternate forms of writing it.
There's a different version of the same function in the encoder,
but they're not identical - the encoder version has got stricter
alignment requirements.
If someone can confirm that it is ok to use the function from the
encoder, pixel_sad_neon.S in processing could be deleted, and the
encoder version moved to codec/common instead.
This avoids using a separate thread for handling pUpdateMbListEvent
events, and later allowing using the encode exit event on unix instead
of pthread cancellation.
This allows using the same codepath for both unix and windows
for distributing new slices to code to threads.
This also improves the performance on unix - instead of waiting
for all the current threads to finish their current slice
before handing out a new slice to each of them (where the threads
that finish first will just wait instead of immediately getting
a new slice to work on), we now use the same logic as on windows.
In one setup, it improves the performance of encoding from ~920 fps
to ~950 fps, and in another setup it goes from ~390 fps to ~660 fps.
(These tests were done with the SM_ROWMB_SLICE mode, which
heavily exercises the code for distributing new slices to the
worker threads.)
The extra WelsEventSignal call on windows where it isn't strictly
necessary doesn't incur any measurable slowdown, so it is kept
without any extra ifdefs to keep the code more readable and unified.
On arm, the exact same detection is done in WelsCPUFeatureDetect,
but in the x86 version of that function we use x86 cpuid for getting
the core count, and this is not available on all processors. For the
case when cpuid can't tell the core count, use the NDK function as
higher level API.
The thread lib itself doesn't build properly on android yet, but will
do so soon.
This allows making the WelsMultipleEventsWaitSingleBlocking
function work properly in unix, without polling. If a master
event is provided, the function first waits for a signal on
that event - once such a signal is received, it is assumed that
one of the individual events in the list have been signalled as
well. Then the function can proceed to check each of the semaphores
in the list using sem_trywait to find the first one of them that
has been signalled. Assuming that the master event is signalled
in pair with the other events, one of the sem_trywait calls
should succeed.
The same master event is also used in
WelsMultipleEventsWaitAllBlocking, to keep the semaphore values
in sync across calls to the both functions.
All users of the function passed the value corresponding to
"infinite", and the (currently unused) unix implementation of it
only supported infinite wait as well.
This avoids having to hardcode the names of devices that don't
support neon.
The devices that don't support neon don't run the armv7 variants
of iOS binaries at all - they would need to be built for the armv6
architecture. (Building for armv6 isn't supported at all in
modern iOS SDKs.)
Therefore we can simply use the __ARM_NEON__ built-in compiler
define to check if NEON code is allowed in the current build,
and have the WelsCPUFeatureDetect function return flags accordingly.
The only thing this disallows is doing an armv6 build which would
optionally enable neon code at runtime if run on an armv7 capable
device, but since Apple allows you to build the same binary for
armv7 separately in the same app bundle, and since armv6 building
isn't even possible in the current iOS SDKs, this isn't really a loss.
This is in contrast to the android builds where the armv7 baseline
does not include NEON.
This avoids the risk of namespace collisions for named semaphores
(where the names are global for the whole machine), on platforms
where we strictly don't need to use the named semaphores.
This unifies the event creation interface, even if the event
name itself is unused on windows, allowing use the exact same
code to initialize events regardless of the actual platform.
Some ifdefs still remain in the event initialization code, since
some events are only used on windows.
There is no point in doing a timed wait here - there's no work
that we can do if the wait timed out, and sleeping for 1 ms
inbetween doesn't help, it only adds potential extra latency
to reacting to threads that need more work to do.
Typedeffing WELS_EVENT as sem_t* makes the typedef behave similarly
to the windows version (typedeffed as HANDLE), unifying the code
that allocates and uses these event objects (getting rid of
most of the need for separate codepaths and ifdefs).
The caller of the function should not need to know exactly which
implementation of it is being used.
For the variants that don't support detecting the number of cores,
the pNumberOfLogicProcessors parameter can be left untouched
and the caller will use a higher level API for finding it out.
This simplifies all the calling code, and simplifies adding
more implementations of cpu feature detection.
