Continuing from PR #8220.
Here we change all of the references from the old ref-counting ways
to the new ref-counting structs and mechanisms. There should be no
functional change.
- Cache the render buffer in the render pass strucutre
- Enable the proteded path in the Render Target
- Make sure we build the protected version of the depth/color in the swap chaing
- Minor cleanup/restrucuring of the code
On ES2 devices (or in forceES2 mode), we emulate the sRGB swapchain
in the shader if the h/w doesn't support it. In that case, the emulation
is controlled by a uniform that technically lives in the frameUniforms
block. However, the frameUniforms buffer is not updated, instead,
the uniform is manually set. Unfortunately, the UBO emulation
overrides it with the uninitialized variable.
BUGS=[377913730]
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).
By providing a queue and the family index, we can now create
protected comand buffers that will be submitted to a protected
queue. The main abstraction is in VulkanCommands.h where we
introduced a CommandBufferPool.
Also did refactor on the "mStorage", fences, and semaphores of
the original VulkanCommands so that each buffer is associated
with one fence and one semaphore.
Feature flags are intended to be used when a new feature is added to
filament and have generally two purposes:
1) during feature development, the feature can be implemented but
disabled which can help developing large features. This way the
feature can be tested by stakeholders while it's being developed
without impacting other clients.
2) once a feature is ready, its flag can be enabled by default, but
in case the feature breaks something or has unintended consequence,
clients have the option to turn it off.
Feature flags are intended to have a relatively short life span, i.e.
once a feature is stable, the flag fill be removed.
There two types of feature flags. Constant feature flags can only be
set during Engine initialization via Engine::Builder. Non-constant
feature flags can be set at any time.
Feature flags SHOULD NOT be used as configuration or settings.
Feature flags are designed with a few ideas in mind:
- they are very cheap to check inside the engine
- non-constant flags can easily be toggled using ImGUI
We add a set of classes to the vk backend that will enable
cleaner ref-counting.
In particular, all allocation from the HandleAllocator will be
wrapped within a resource_ptr<> smart pointer. This struct will
maintain a count that will increment/decrement with respect to
references (similar to std::shared_ptr).
This commit only introduces the new classes/structs and does not
actually make any functional difference. A follow-up commit will
make the switch to use the smart pointer.
We also put VulkanFence and VulkanTimerQuery in a different header
because we will need to depend on them separately in the follow-up
(reason: they are accessed on the backend thread but allocated on
"sync"/filament thread).
Adding the basic mechanisms for creating and managing the protected
state. We also create the queue and get it. Finally we allocate
protected memory. Also removed some of the shared context logic
The goal of this PR is to get closer to being able to run all
FrameGraph passes in parallel. To achieve this we need all data
consumed by the "execute" closure of the FrameGraph passes to be
immutable or thread-safe. We also need the passes to never use the
Engine's global `DriverAPi&` object.
Specifically in this PR, we turn as many objects to `const` as possible
without major changes, and we pass the `DriverApi&` object as parameter
to render passes.
This work is far from being complete. So we also annotate with FIXMEs
all the places we can identify will be problematic (there are probably
others).
The main remaining issues are:
- main allocator is not thread-safe
- some places take a non-const View, Scene or Engine
- lazy allocation of materials and material instance usages are not
thread-safe.
This PR shouldn't change any behavior.
Move a lot of the code from beginRenderPass() to the initialization
of the RenderTarget. This will save us a bit of CPU when
RenderTarget is re-used.
We also reduce the size of the VulkanRenderTarget handle and put
must of the caching bits into a heap struct.
When multiview is enabled with the combining debug option toggled on, we
use an intermediate buffer that requires us to use the entire area of
the buffer as the viewport. Use xvp in this case.
* Capture the last win32 error immediately after failing win32 API functions are called in order to log it correctly. Prior to this change, intervening win32 API calls could clear the error code and it would not be logged.
* Oops fix bad whitespace in previous commit
In some cases, users set materials first without providing render primitives, which has incurred the attribute mismatching warning. This isn't helpful because users don't know what action they should take to remove the warning.
Emit the warning only when the primitive handle is initialized so the AttributeBitset is properly populated.
BUGS=[372755205]
RenderPass is now tracking the scissor state locally so it can avoid
re-setting the scissor when it doesn't change.
We also consolidate the scissor override and the scissor-viewport in
RenderPass::Execute.
RenderPass is now tracking the scissor state locally so it can avoid
re-setting the scissor when it doesn't change.
We also consolidate the scissor override and the scissor-viewport in
RenderPass::Execute.
- the main goal of this change was to move some state changes outside
of loops, usually with mip generation.
- for instance bindPostProcessDesciptorSet() must now be issued
manually (and can be done outside the loop)
- we also don't set the scissor for each pass
- we also move prepareMaterial() outside of getPipelineState(), it's
now done in PostProcessMaterial::getMaterial().
- We use PostProcessVariant instead of uint8_t everywhere
In the end we have three drawing helpers:
- commitAndRenderFullScreenQuad() which updates a material instance,
binds the corresponding material and draws a full screen quad.
- renderFullScreenQuad() which just renders a full screen quad.
- renderFullScreenQuadWithScissor() which does the same but scisorred
Additionally, we have the following helpers for getting materials and
instances:
- PostProcessMaterial::getMaterial(): which returns the FMaterial
- PostProcessMaterial::getMaterialInstance(): which is now a helper
returning a material instance from a PostProcessMaterial or FMaterial
Most of the change is pluming through these API changes.
