This is now the default, and the tone mapper used
is now the same on desktop and mobile.
In the future this will allow us to implement many features such as
color grading at no cpu cost.
OpenGL allows vertex shaders to consume attributes that are never
assigned values from a vertex buffer. When this occurs, GL provides a
default zeroed-out value, or a value from the most recent call to
`glVertexAttrib*v`.
Vulkan does not allow this, so our Vulkan backend provides dummy data by
re-using the position buffer, which we know exists. This was an existing
hack, but it did not always assign a compatible type, which resulted in
validation spew with gltf_viewer + BusterDrone.
This fixes one of the two bugs reported in #2573.
Vulkan complains if a pipeline declares an integer vec2 attribute but
the shader consumes it as "vec2" rather than "ivec2". gltfio was doing
this when supplying dummy texture coordinates.
This fixes one of the two bugs reported in #2573.
Since AO is computed at 1/4 resolution, it is necessary to upsample
the AO buffer. Until now this was done with a bilinear tap, which is
less than ideal as it can creates jaggies at edges.
High quality upsampling can now be enabled and uses a bilateral filter.
The cost is about 2.0 ms at 250MHz on Pixel 4. ES3.1 is required.
SSAO starts at 1/4 resolution, and because we used derivatives
to calculate a cheap pre-blur, the output was mostly 1/4 resolution
of that, leading to 1/4 of the destination pixels being mostly identical.
This, in turn caused sampling issues when reading the SSAO buffer during
the color pass.
We fix this by getting rid of the pre-blur, and increasing slightly the
size of the gaussian blur from 9 samples to 13, which increases the
SSAO pass time by 20%, or 0.3ms at 430 MHz on Pixel 4.
With this change and bilinear filtering in the color pass, we get rid
of all the sampling artifacts.
until now we allowed any resolution for SSAO, but it didn't make
much sense, especially that the depth pass is now used for other things.
To keep things more manageable, we only allow 0.5 and 1.0 scale
factor settings (respectively quarter and full resolution).
Adding this for completeness, although the feature triggers a known
issue with Chrome's WebGL implementation that emits an error when
source and destination textures of a draw call are the same.
Refracted objects could be drawn on top of opaque objects that were
closer to the camera.
Du to a typo, we were not reusing the existing depth buffer during the
refraction pass.
Fixes#2576
This contains the following two fixes, but the second fix is more
important because it prevents an actual validation error on Android.
1. The query pool bitset was written in the main thread but read
in the driver thread, this is now protected with a mutex.
2. Querying a timestamp before it has been written into the command
buffer was still causing validation errors, despite the fact
that we are now properly using the AVAILABILTY flag. This is a
CPU-side synchronization problem and can therefore be fixed using
std::atomic<bool>.
This was sometimes causing a cascade of log messages and swap chain
re-creations on Android.
To support resizing, we still re-create the swap chain when encountering
VK_ERROR_OUT_OF_DATE_KHR.
Suboptimal means: "A swapchain no longer matches the surface properties
exactly, but can still be used to present to the surface successfully."
It is convenient to control the debug_info extension and the validation
layers from one central place. This makes it easier to force-enable
validation in Release builds to validate optimized shaders.
Since we are still on Vulkan 1.0, we cannot use SPIR-V 1.3.
If we try to do so, this error is generated:
Invalid SPIR-V binary version 1.3 for target environment SPIR-V 1.0
In non-optimized builds, we were already generating spirv 1.0, but
when we enabled the shader optimizer, we generated spirv 1.3.
This bug has actually been around forever, but we did not notice because
we were only invoking the optimizer in release builds, which does not
enable validation.
We cannot upgrade Vulkan 1.1 because the latest LunarG SDK for macOS
does not support it.
The value we pass to spvContextCreate() is not SPV_ENV_UNIVERSAL_1_3,
which is what we use in GLSLPostProcessor.
Also add a call to spvValidateBinary(), which would have caught this
oversight.
This allows FrameSkipper to work on desktop.
Similar to the GL backend, we can only query the fence from tick().
The Vulkan spec stipulates that a fence object cannot be accessed by
more than one thread simultaneously. My initial implementation violated
this, which was caught by the validation layer.
This allows to never store/load to main memory the HDR color buffer,
saving precious bandwidth. This mode relies on the
ext_framebuffer_fetch extension being present and can't be enabled
with certain features (currently msaa, Bloom, DoF).
This will eventually be supported on Metal and Vulkan as well.
this is intended to be temporary until we properly add support
for vulkan's subpasses. this PR just helps us activate
ext_framebuffer_fetch on select materials.
The presence of a special Gradle property is now used to exclude Vulkan
support from the build. By making Vulkan "always on" for local
development, we can avoid stale CMake cache issues that arise from
toggling the Gradle property. It also lets you avoid adding the flag
to Android Studio preferences.
This is motivated by testing and does not indicate production readiness.
Clients still need to pass VULKAN into the Engine constructor to select
the Vulkan backend.
To keep APK size down and keep CI fast, we are continuing to exclude
Vulkan from official Android builds.
After syncing this change, you might need to use `./build.sh -c` to
clobber various build caches.
