- update the pools sizes for metal and vulkan, which were very outdated.
- add debug code on all backends to print the size of each handle
(with a compile time switch)
The most important change is that now the 3 pools of HandleAllocator
are sized so that each can accommodate about the same amount of handles.
This makes it easier to reason about. The total amount of handles is
three times that, since there are 3 pools.
We also try to allocate the buckets so that handles are evenly
distributed, however, that's very hand wavy.
With the current setup the number of handles per pool is as follows:
- GL : 3240 / pool / MiB
- VK : 1820 / pool / MiB
- MTL: 1310 / pool / MiB
* Automatically flush CommandStream
When generating commands, we now automatically flush the CommandStream,
so that we're guaranteed to not overrun the circular buffer.
* clenaup CircularBuffer implementation and API
Also fix a bug in DEBUG mode that could corrupt the CircularBuffer, it
was due to a wrong debugging code attempting to clear the unused
area of the buffer (this was wrong because in "ashmem" mode, there are
no guaranteed unused areas).
* Fix a couple threading vs. allocations
- prepareVisibleLights was run on a dedicated thread (via JobSystem),
but was using its own local ArenaScope. This is wrong because it
could reset the root arena at any later point. This is fixed by
just not using a local ArenaScope.
- related to the above, the root Arena (LinearAllocatorArena) didn't
use a locked policy, which cause also cause problems since some
allocations are done off the main thread. We now pre-allocate the one
buffer we need.
This PR also renames some variable and types to improve readability.
* Rework RenderPass to improve allocations and API
RenderPass now is a fully immutable object that gets constructed with a
RenderPassBuilder. RenderPassBuilder can be passed around and doesn't
do any (major) allocations.
All RenderPass allocations and heavy lifting is done in
RenderPassBuilder::Build().
Additionally, RenderPass cannot be copied anymore.
Where allocations happen is now much clearer.
* new LinearAllocatorWithFallback
LinearAllocatorWithFallback is a linear allocator that can fall back
to the heap allocator. We use it for the high level command buffer to
avoid crashing when running out of memory.
FIXES=[277115740]
* Update filament/src/RenderPass.h
Co-authored-by: Powei Feng <powei@google.com>
* Update libs/utils/include/utils/Allocator.h
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
- Add methods for adding attributes to the input mesh
- Add method in TangentSpaceMesh for when user provides the
tangents
- Separate client-side Algorithm enum from implementation algorithm
(AlgorithmImpl)
- Fix CMake config for combining static libs
32 sample may be more suited to 2x upsampling, it gives 8 samples per
high-res pixel (instead of 4). This is also what FSR 2.0 is using,
which is useful for comparing.
This has caused issues and over time we have reduced the use of
spinlocks, it was only used in few places and we still have evidence
that it's causing ANRs.
We use utils::Mutex instead which is a low overhead mutex implementation
on Linux systems.
FIXES=[321101014]
it was incorrectly mapping the equirect image to a cubemap due to a
typo in our overload of atan2 which was swapping its parameters.
atan2 is now removed, and we use atan(y,x) instead. Also modified the
code slightly so it matches almost exactly cmgen's.
FIXES=[320856413]
* Bokeh aspect ratio
new DoF option to set the bokeh aspect ratio, this can be used to
simulate anamorphic lenses
* Update android/filament-android/src/main/java/com/google/android/filament/View.java
Co-authored-by: Powei Feng <powei@google.com>
* Update web/filament-js/filament.d.ts
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
See #7415 for a more detailed description of why this change is necessary.
The remaining variants which are filtered from FL0 materials are all related to
lighting, so further hacks like this won't be necessary.
Future work involves properly supporting differing sets of variants based on
shader language.
* TAA improvements
- fix variance + AABB history clipping (we were computing the union
of both AABB instead of the intersection).
- added a setting for the variance parameter
- added a setting for the jitter pattern
- improved some default values
- fixed a few comments
- smaller code tweaks to facilitate future improvements
Material constants (a.k.a: specialization constants) can only be set
during Material creation through Material::Builder.
This change somewhat relaxes that limitation by allowing constants to
be set at runtime on Material directly.
Currently this new API is still private and only supported on FMaterial.
This feature works by invalidating the HwProgram cache of the concerned
Material, causing a shader recompile per variant; so this API is costly
and should be used only for debugging or during app/game configuration.
The TAA material is modified to use constants instead of #defines for
various settings and those are exposed in TaaOptions as well is in
ViewerGui. So with this change all aspects of the TAA material can
be changed at runtime.
Even if skinning is not fully implemented on FL0, we have clients which depend
on materials with skinning variants that otherwise could easily be converted to
FL0 materials. There are two proper ways to deal with this:
1. Support skinning/morphing in Feature Level 0.
2. Allow ESSL 1.0 code and ESSL 3.0 code to support different sets of variants.
However, the simplest solution is to just include skinning/morphing variants,
but disable codegen for ESSL 1.0 code, making them identical to the base
variants. This shouldn't increase the file size much due to the dictionary
deflation. Of course, skinning will not work correctly on FL0, but this has
always been the case. Future work here would be to properly implement one of the
two solutions described above.
The CL introducing the ESSL 1.0 chunk in materials inadvertently disabled
optimizations for said code. This commit reintroduces those optimizations and
fixes associated bugs which manifested. In particular, spirv-cross was
generating uints for bools; this has been fixed with a hack. Additionally,
spirv-cross is now compiled with exceptions enabled so that matc can gracefully
fail and show the code which failed to compile rather than abruptly aborting.
Since #7358 is blocked by an upstream spirv-cross issue, we can at least do a
bit of preprocessor optimization for ESSL 1.0 code in the meantime and introduce
the FILAMENT_EFFECTIVE_VERSION preprocessor definitions.
- gltfio: Enable -Wall -Werror for gltfio_core
- gltfio: Fix various errors that were missed warnings
- matdbg: switch from std::atomic_uint64_t to
std::atomic<uint64_t> for older clang
we recently added calls to Material::compile in gltfio to precompile
materials are they are discovered. that wasn't a good call, because
this should be the responsibility of the app, not of gltfio, at least
not without an option.
This is now done in gltf_viewer. We need something similar for
Android.
Bugs #7318, #7336
Drag and dropping a gltf folder was broken:
- the handle didn't find the gltf file on drag&drop
- the ResourceLoader cached the asset path
- don't exit(1) when drag&dropping an invalid file
- Make sure matinfo works by selecting a default backend in the
absence of activeShaders.
- Add options to select backend in matinfo mode.
- Workaround cursor misplacement for monaco
- Refactor menu sections into a common element.
First, this commit introduces some very simple bugfixes regarding ES2
compatibility related to postprocessing.
Second, this commit adds support for creating textures specified as R8, SRGB8,
and SRGB8_A8 in ES2. R8 is trivial: just use GL_LUMINANCE instead. The sRGB
formats, however, are maybe a bit more controversial. As implemented, they
instead just use the equivalent non-sRGB formats. This is of course technically
incorrect. There are a few approaches to how to add sRGB compatibility for ES2
that I can think of.
1. Do a bunch of complex shader nonsense in matc. Maybe even traversing the AST
and ensuring any texture lookup of a texture flagged as sRGB uses some
compatibility function. This would require static analysis to track if samplers
are reassigned to another variable, for example. This of course also breaks down
if you don't know at compile time if the shader will receive an RGB or an sRGB
sampler, or if the shader should be able to support both RGB or sRGB samplers.
Really only worth mentioning here for the sake of completion.
2. You could also generate simple compatibility functions to look up each
sampler, which would only apply to FL0 materials.
First, we would have to extend the material format to be able to explicitly
"color" a sampler as sRGB or not, like:
```
parameters : [
{
type : sampler2d,
name : albedo,
precision : medium,
colorSpace : srgb,
},
{
type : sampler2d,
name : normal,
precision : medium,
colorSpace : linear,
}
],
```
Then, the following GLSL code would be generated.
```glsl
\#if __VERSION__ == 100
vec4 texture_albedo(vec2 position) {
return sRGBtoLinear(texture2D(materialParams_albedo, position));
}
vec4 texture_normal(vec2 position) {
return texture2D(materialParams_albedo, position);
}
\#else
vec4 texture_albedo(vec2 position) {
return texture(materialParams_albedo, position);
}
vec4 texture_normal(vec2 normal) {
return texture(materialParams_normal, position);
}
\#endif
```
Finally, at runtime, if a sampler is "colored" one way or the other, we would
verify that only the appropriate kinds of samplers are bound.
I'm actually very partial to this solution. Since sRGB compatibility is only a
concern on ES2, we can generate this code only for FL0 shaders, which already
require GLSL shader authors to care about ESSL 1.0 compatibility by calling the
appropriate `textureXX` functions. Additionally, it provides a layer of
high-level validation that texture lookups are correct, even if a real ES2
context is not available on the device being tested.
3. Leave it entirely up to the client. (What this commit does.) This leaves
client code ripe for making mistakes, but luckily, we can go back and do
solution 2 whenever. If specifying a color space for a sampler remains optional,
then if this feature is retrofitted in the future, client code will continue to
compile.
