This prevents a SwiftShader crash and/or a slew of "no texture bound"
warnings that would appear when the client provides an IBL without
providing reflections texture, which should be a valid thing to do.
Note that it is okay to declare a sampler in GLSL that never gets bound,
as long as it is never sampled from. Since we always sample from the
IBL specular texture, we should always bind something to it.
With Vulkan, this warning would sometimes be a false positive. It could
trigger for internal samplers like `ssao` and `structure`, even though
they were not declared in SPIR-V.
With OpenGL, this warning would never be a false positive because it has
the luxury of calling `glGetUniformLocation`.
This adds a private attribute to our samplers called `strict` that
indicates whether or not a sampler should always have a bound texture.
For now the only strict samplers are the custom ones declared in the
user's material.
At some point I think we should consider adding `spirv-reflect` to our
tree to help with problems like this.
This fixes a bug seen with client applications that use ClearOptions
instead of Skybox, and one or more offscreen RenderTarget objects.
These apps would see junk pixels because Filament would only clear the
first render target in the frame.
The fix is to factor some the flag-setting logic in `beginFrame()` into
a private method, and call this method from `render()` each time
the user-level RenderTarget has been changed.
I wrote a simple C++ demo to reproduce the issue and to verify that
this fix works.
This moves all Vulkan entry points into the bluevk namespace
to avoid conflicts with other Vulkan loaders.
This also updates the header files and loader code to version 1.2.159 of
the Vulkan spec, which is currently available at the following links.
https://khronos.org/registry/vulkan/specs/1.2/html/vkspec.html87451c55aa
Fence.cpp:
My previous fix to the fix was insufficient because a signed integer
overflow could still occur as follows (this was observed in an internal
test at Google).
If the conditional on line 87 is true, then a clamped value is passed
into `wait`, which causes the conditional on line 133 to fail, which
causes `wait_for` to be called inappropriately, which is where an
overflow would occur.
MetalHandles.mm:
This is more theoretical, but to prevent potential integer overflow
within STL, I think we should call `wait()` rather than `wait_for()`
when an infinite timeout is desired.
This is our fourth fix to fences in since November 2; see also dcca236,
e9c9e45, and 8969416. :)
FFence::wait() has some logic that tests if "timeout" is equal to
FENCE_WAIT_FOR_EVER, which is actually impossible because it would
be modified by the clamp in this situation.
In practice I think this oversight would not cause any problems. I
noticed it while reviewing the code.
To recap why the clamp exists: according to the ISO C++ spec, the
"nanoseconds" duration in chrono is at least a signed 64-bit type, but
our sentinel constant might not (and does not) fit within this range.
Note that this API is on the loader rather than the asset. This is
because the loader knows how to create Filament entities by traversing
a cgltf node hierarchy.
Animation on dynamically added instances is not yet supported.
We did not add destroyInstance() because gltfio favors flat arrays for
long term storage of entity lists and instance lists, which would be
slow to shift. We also wish to discourage create/destroy churn since it
is more efficient to pre-allocate instances and selectively add them
into the scene.
Fixes#3137.
Release builds do not call cgltf_validate() so it was possible to
read out-of-bounds animation data when encountering a badly formed glTF
file with mismatched counts between sampler inputs and outputs.
This fixes a slew of validation warnings and errors seen when multiple
subpasses are enabled, starting with:
Attachment 1 not written by fragment shader; undefined values will
be written to attachment
The Vulkan driver was using the same color attachment list for both
subpasses, so the first subpass had unused attachments.
Note that Vulkan makes a distinction between color attachments and input
attachments and requires separate lists to be supplied for each subpass,
but our Driver API consolidates everything into a single list. This
should perhaps be refactored at a later date.
This prepares for #3137 by moving the mesh cache and material instance
cache out of the loader (where they were transient anyway) and into the
actual asset. This paves the way for a `createInstance()` API.
