This fixes validation errors and makes a first pass at simplification.
VulkanTexture now tracks image layout using RangeMap, which paves the
way for further simplification.
__ANDROID__ is always set by the toolchain and less likely to cause
conflicts than ANDROID. This change also removes the -DANDROID flag
we set ourselves in our toolchain CMake files since we don't need
it anymore.
When supported and enabled, resolve MSAA using an HDR aware filter,
which improves anti-aliasing quality.
This is only supported with backends that support multi-sampled
framebuffer-fetch. Currently, only Metal on iOS and GLES.
Update remote ui.
All APIs that take a callback as argument now also takes a
CallbackHandler* which is a new interface used to dispatch the
callback.
CallbackHandler* can always be nullptr in which case the behavior is
unchanged.
When CallbackHandler* is specified however, it is used to dispatch the
callback: its post() method is called from a service thread as soon
as possible (this will NEVER be the main thread), CallbackHandler::post
is then responsible for scheduling the callback onto the thread the
user desires. This is intended to make callbacks interoperate with
the platform/OS's own messaging system.
The main issue that gets fixed here are:
- VK_IMAGE_LAYOUT_UNDEFINED cannot be used if the image content is to
be preserved after the transition. Unfortunately, there is more than a
few places in the VK backend where we use VK_IMAGE_LAYOUT_UNDEFINED on
images that are later used as sources.
- accessing an image memory from the host is only supported if the the
layout is PREINITIALIZED or GENERAL. However, images in the staging
pool were transitioned to other layouts and put back into the pool,
later they would be mapped/memcpy'ed into. Instead we now always use
the GENERAL layout and never change it.
- images that where in the pool where transitioned using the miplevel
of the texture we were copying into, however this didn't make sense
because images from the pool don't have mip levels.
As part of these fixes, we also refactor imageLayoutTranstion(),
because there was two copies of this function, one specific to texture
and another one more generic. We now always use the more generic one,
with a new helper for textures.
Note: didn't fix "readPixels" which has at least problem (1), because
it's a tricky implementation, and it requires more toughts.
This is just a minimal change to get the R_INTEGER format to work.
- if src/dst types are identical, just copy (this avoids a mul and a div)
- add R,RG and INTEGER types
* Use a clip space that matches our screen space for the z axis
We now set the projection matrix so that the clip space for the z
axis follows the inverted DX convention, i.e.: z_clip between 1 (near)
and 0 (far), which matches our screen space.
Note that the actual clip space in the GPU can revert to the "inverted
GL convention", i.e.: z_clip between -1 and 1, if the clip_control
extension is not present. In that case the precision benefits are
mostly lost.
Also note that there shouldn't be any user facing changes.
The projection matrix at the API level, still follows the GL convention.
Also, currently, the VERTEX_DOMAIN_DEVICE for materials also keeps
the GL convention (this is corrected in the vertex shader).
The gist of this change is to move the "reversed DX" mapping from the
vertex shader to the projection matrix.
* Update shaders/src/getters.vs
Co-authored-by: Ben Doherty <bendoherty@google.com>
Co-authored-by: Ben Doherty <bendoherty@google.com>
This all started because the gl backend version of blit() didn't
handle color attachments other than COLOR0 *AND* would actually
corrupt the destination attachments other than COLOR0 if present.
This is due to how very stateful the gl API is.
Since this is a case we're not running into currently, the GL backend will
now assert in that case.
Updated the Vulkan and Metal backends to also reject blits where
color buffers other than COLOR0 are requested.
Ultimately, we need to change entirely our backend blit API so it
is less GL centric.
It looks like they are not working, at least with the current version
of the drivers and/or MoltenVK. It is not impossible that we have a
bug in how we set the subpasses as well. This will need more investigation
later.
Previously we were zero filling the data blob used to store all Vulkan
handles. This occured in VulkanDriver::alloc_handle().
There were several places that depended on the zero fill. These
have now been fixed up so that the handle can be constructed in a
more natural way.
Also: remove the OPENGL specific constant from HandleAllocator. This
breaks in non-CMake build systems (e.g. Bazel) that do not provide the
constant at a global level.
1) Add a missing destroyTexture to the test, which I believe fixed
the Metal assert that I was seeing, as well as some Vulkan validation
warnings.
2) Add a flushAndWait() utility to BackendTest, which is useful for
diagnostics.
3) Fix a layout validation issue in VulkanSwapChain for empty render
passes.
This makes the car load in 3 seconds instead of 30 seconds on Mali.
On devices that have bufferImageGranularity set to 1 in the
VkPhysicalDeviceLimits caps structure, we observe that vmaCreateBuffer
can be two orders of magnitude faster than with devices that have a
higher value for their bufferImageGranularity.
According to the Vulkan spec, the bufferImageGranularity aligment
constraint needs to be honored only when linear and non-linear resources
live next to each other in memory. Since all VkBuffer objects are
linear, we can allocate them all from the same pool and ignore the
alignment constraint.
VK debug markers do not show up in an AGI system trace, but we can sneak
them in by using debug_utils to assign labels to VkFramebuffer.
Note that the debug_utils extension is enabled only when launching your
app from AGI.
This fixes most of the warnings that are emitted by the relatively new
SYNCHRONIZATION_VALIDATION feature that LunarG provides.
This commit does not fix a warning that is emitted when SSAO is enabled,
when we sample from the currently bound depth attachment. This one is
tricky to fix.
Newer versions of MoltenVK seem to behave similarly to Android,
so there's no need to separate codepaths. I tested this by not only
resizing the window, but also dragging between displays with different
pixel ratios, and rotating on Android with & without `orientation` in
`configChanges`. I also tried our headless unit tests.
This has no behavioral changes, it's mostly just moving code around,
except that VulkanDriver::createSwapChain() is simpler now, and some
of the logic in beginRenderPass() makes more sense too.
This removes the useless `VulkanSurfaceContext` structure by moving
its data directly into `VulkanSwapChain`. Also created a new cpp file
just for the swap chain wrapper, which makes `VulkanContext` much less
unwieldy.
Vulkan does not permit the GENERAL layout when the depth buffer that is
currently being used for depth testing is also sampled from.
This (finally) fixes the last validation error that we were silencing,
which would occur only when SSAO was enabled.
MATERIAL BREAKAGE: this change breaks materials
In order to use one less sampler, we now use a UBO instead of a texture
to store the "froxel records". Currently this UBO is limited to 16KiB
vs. 64KiB before with the texture.
We also handle running out of record space better, by using a predefined
record that has all the lights in the scene. This way the scene will be
rendered properly, albeit at a potentially large performance cost.
This fixes the "descriptor set fragmentation" error that we would see on
Mali.
The pipeline cache now maintains an arena of descriptors that can be
re-used. We call this an "arena" to avoid confusion with
VkDescriptorPool.
Descriptors are returned to the arena only when they are not in use
by any pending command buffer. This allows them to be mutated safely
without worrying about synchronization.
The API of the pipeline cache is now easier to use. Internally, it now
maintains separate pipeline and descriptor bindings for each command
buffer, since that's how Vulkan works.
