* Try to clean up asset folders for sample apps.
This removes the build step where we copy a subset of assets, and makes
it so that FilamentApp hands out a "root path" for assets. For now this
is determined based on the location of the executable. This allows
developers to launch samples from any CWD.
Closes#11
* Restore asset copy to build.
computeLightTree() takes a list of light as
a bitfield and produces a depth-first
binary tree array that can be used to efficiently
check which lights volumes contain a given z
coordinate in screen space.
Currently computeLightTree() produces the array
locally on the stack, which isn’t useful, but
before we can make use of it, a lot of other
things have to happen.
* better froxel records compression
We used to compress froxel records by reusing the
previous record on the left if it was identical,
now we additionally check the record above if
that fails.
In practice this saves 10% to 30% space in the
froxel record buffer, which is a scarce resource
for us.
e.g. if a light occupied 3x3 froxels in a given
z-slice, without compression 9 records would be
used, with left-only compression, only 3,
and with left+above compression, only 1.
* use size_t for in and out parameters
this helps the compiler in many places, not
having to cast from 64 to 32 bits.
* implement bitset’s any() and all() operations with NEON
* empty froxels are a common case, handle it first
* JobSystem now automatically free Jobs
Until now Job allocation used a linear allocator
strategy which required to “reset” the JobSystem
periodically — typically once per frame in
filament.
This is no longer required. We use a pool allocator
now, which doesn’t add much overhead. It does
use a spin-lock for thread-safety though, since
we assume very little contention, this shouldn’t
be a problem.
* Thread Safe Object Pool Allocator
A lock-less, thread-safe object pool allocator,
now used for storing JobSystem’s jobs allocations.
This gets rid of the spin-lock introduced in the
previous cl.
We spawn MAX_LIGHTS/32 (currently 8) jobs and
multi-threading is active as soon as we have more
than one light. All jobs work on disjoint buffers
to avoid false sharing between threads.
It’s possible to adjust roughly the number of jobs
by changing the group size (currently 32). However
this also affects vectorization.
With the current parameters, with 256 lights max
we get 8 jobs, and 4 spot-light test / froxel.
Instead of building a list of froxel per light,
we now build a bitfield of lights per froxel.
To keep the code efficient we have to split
the bitfield array in 4, so that we can use
multiple threads without having them or’ing
each other’s cache-lines.
This data structure is also what we want in
froxelizeAssignRecords(), and the conversion from
one format to the other is much faster.
Our internal data structure is now 256 KiB
instead of 2 MiB. It would be 1 MiB for 1024 lights
(down from 16 MiB)
Additionally, because the code is simpler, we get
more vectorization, especially with spot-lights.
One draw-back of the current version is that
multi-threading happens only every 64 lights.
This will be fixed later.