The commit 1747ae8f5a enfoces a correct
order for releasing resource. Fix the order to avoid crashes.
Make some samples to use the DEPTH32F format for better compatibility.
Some manufacturers don't fully support DEPTH24 on Vulkan. E.g., AMD
Radeon PRO W6400
When targeting Vulkan with multiview, the shader
code generator was using the OpenGL extension
and built-in variables, which are not supported on
Vulkan.
Changed it to use GL_EXT_multiview instead of
GL_OVR_multiview2 when the target API is Vulkan.
* Introduce FrameGraphInfo class
* Move the assignment into pimpl
* Make ctors explicit
* Add ctors to fg info structs
* Revert the macro change to align with existing
* Address the comments
* Remove pimpl and move func def to .cc
* Fix
* Convert the FrameGraph to FrameGraphInfo
* Initialize and update debug server on engine side
* Fix compile error
* Address the comments
* Update
* Use camelCase
* Use camelCase
* Update
This commit renames all shader snippet files to conform to the newly
introduced naming convention outlined in README.md.
The new naming convention uses a `prefix_name.suffix` format to clearly
indicate the purpose and target shader stage of each snippet. This
improves the overall organization and readability of the shader code,
making it easier to understand how each snippet contributes to the
shader generation process.
No functional changes were made to the shader code itself or source
code. This is purely a refactoring for clarity and maintainability.
* Introduce FrameGraphInfo class
* Move the assignment into pimpl
* Make ctors explicit
* Add ctors to fg info structs
* Revert the macro change to align with existing
* Address the comments
* Remove pimpl and move func def to .cc
* Fix
* Address the comment
* Remove redundant qualifiers in filament public headers
* remove redundant qualifiers in filament implementation
* remove redundant qualifiers in libutils public headers
* remove redundant qualifier for libutils implementation
* remove redundant qualifiers for libmath
* use is_same_v<> instead of is_same<>
* bring back Builder::name()
we keep Builder::name() on all object, and forward to the MixIn class
that does the implementation, so that we have correct documentation, and
better IDE completion.
* add missing const parameters in filament's implementation
* various source cleanup
- missing includes
- missing const
- C cast style
- superfluous inline keyword
* validate MaterialInstance references when destroyed
With this change we now enforce two things:
- All MaterialInstance of a Material must be destroyed when
destroying said Material. This has always been a documented
requirement of the public API, but wasn't enforced (only
a warning was printed).
This new assertion is unconditional.
- A MaterialInstance, when destroyed is no longer in use by any
Renderable.
So before destroying a MaterialInstance, the user of API needs to
ensure that either all Renderable using that MaterialInstance in one
of their Render Primitives are destroyed, or, that these Renderable
using that MaterialInstance are reset to another one or to null.
There is a new RenderableManager::clearMaterialInstanceAt() that can
be used to clear a MaterialInstance on a Render Primitive.
Additionally, a Render Primitive with a null MaterialInstance is now
silently skipped during rendering, instead of a null-dereference.
Finally, that second assert is protected by a new feature flag:
"features.engine.debug.assert_material_instance_in_use". This flag is
enabled on DEBUG builds and disabled on RELEASE builds by default.
The flag can be changed at any time using `Engine::setFeatureFlag()`.
BUGS=[333907416]
* Update filament/src/components/RenderableManager.cpp
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
This feature is controled by a feature flag and is turned off at this point.
This CL shouldn't change the existing behavior of shadowmap allocation as
long as the atlas feature is not enanled.
When enabled, shadowmap allocations are not limited to layers of the
shadowmap texture, instead, an atlas is used meaning a layer can
be shared by multiple shadowmaps. At the very least this can save
a lot of memory as smaller shadowmaps can be packed together.
Currently this feature breaks some VSM features:
- mipmapping
- blurring
- when inserting an entry at a root other than zero, we need to update
the children count of the root's parent.
- the QuadTree array nodes need to be able to encode enough indices for
the largest "layer" in the tree. With 7 layers the largest one has
4096 entries, so we need 12 bits, not 8.
We use clang-format to format the shader files. Since we assume
clang is necessary for compilation, installing clang-format should
not be too much of an overhead in terms of adding dependency.
Currently, we only support posix systems (macOS, linux).
* Skeleton of fgviewer debug server
* Update the map for fg info
* Add ApiHandler skeleton class
* Format the files
Format the file
* Prevent fgviewer being built before ready
Add comment to fgviewer related lines
Fix cmake commands
* Update the copyright
* Address the comments
Address the comments
* Address the comments
* Specify the debug server
* Fix build options
Fix 3 bugs wrt matdbg:
1. The numbering scheme for materials with same name was buggy
2. The shared depth variants of the default material should also
show up as active material variants.
3. When two instantiation of FMaterial point to the exact same
bits, we still need to treat them as two materials. (Otherwise
we wouldn't be able to modify one of them in matdbg).
If the shared osmesa lib is not found, then we assume that the
library has been compile-time linked via the linker. This is to
accommodate build frameworks where compile-time linking is
preferred.
When tangents are not supplied in a material, all "normals" related
public methods become undefined; remove access to them so we get
compile time errors instead of garbage values in the shader.
* fix a HwProgram leak related to depth variant pre-caching
Materials that don't use a custom depth can share the same program for
all depth variants. We take advantage of that by pre-caching the
depths variants when a program is loaded. The depth variants themselves
are owned by the default material which is created first. When a
material is destroyed it skips deletion of those variants which will
be truly destroyed when the default material is destroyed.
Unfortunately, the default material doesn't contain all depth variants,
in particular, it doesn't have the VSM ones (because it's an unlit
material). On top of that, the way it pre-cached depth variant had
a bug that made it miss some picking variants.
Because of that, these variants were skipped during material destruction
but never actually destroyed, since the default material didn't know
anything about them.
This PR fixes this by making the pre-caching completely lazy. When
any material needs such a "precacheable" variant, it first checks if
the default material has it. If not, it creates the variant, caches it
locally and forwards it to the default material, which implicitly
becomes the owner. Just like before newly created material precache
everything the default material already has.
With this mechanism, it's impossible to have a depth variant without it
also existing in the default material.
This also simplify the non-public invalidate() method, which doesn't
need to populate the pre-cached programs, since this will happen
naturally when needed.
There was also another issue where post-process materials were
handled like regular materials. This didn't cause an problem but was
inefficient since these only have a handful of variants.
* Update filament/src/details/Material.cpp
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
The previous fix attempt didn't work on some test. There are no known
bugs with AtomicFreeList other than tripping TSAN, and it's unclear
that TSAN isn't at fault.
However, switching to using a mutex works fine and doesn't appear to
be slower (it's actually faster with synthetic benchmarks on macOS)
BUGS=[377369108]
I do not think there was an actual error with AtomicFreeList, however
TSAN detected a data race when concurrent pop() happened. In that case,
there is indeed a race, where we can end-up reading data that is
already corrupted by the concurrent pop. However, that situation is
corrected by the following CAS. Somehow TSAN didn't see that.
The fix is strange and consists in replacing:
```
auto pNext = storage[offset].next;
```
with
```
auto s = storage[offset];
auto pNext = s.next;
```
In this PR we also adjust the memory ordering to be less strong. i.e.
we do not need `memory_order_seq_cst`, only the appropriate acquire or
release semantic.
In addition we also make `Node* next` a non-atomic variable again. It
should have been, but was change to placate an older version of TSAN.
BUGS=[377369108]
Previously, we linked against libOSMesa through the linker and
then used dlopen to link against libGL. This is not how libOSMesa
is intended to be used. Instead, we use dlopen on libOSMesa
(via bluegl), which then will map the correct GL methods for us,
and for the OSMesa functions, we also map those functions
from libOSMesa (instead of relying on compile-time linker).
- Both Scene and IBL are holding on to a skybox reference. We
need to make sure the order they are destroyed in right order.
- Reloading IBL should trigger resetting the indrect light in
gltf_viewer.
default parameters were not initialized which could cause them to
be incorrectly evaluated in the shader. this is actually a pretty
crazy bug that has been around since forever and which we were
"lucky" to not run into sooner.
this was exposed with the specular extension that was added recently.
GavinKG
Sungun Park
Rafael Dominguez
Doris Wu
Eliza Velasquez
Evan Mezeske
John Bampton
Powei Feng
Mathias Agopian
Ben Doherty
seker
Guilhem Saurel
Haneul Kim