The corruption seems to be triggered with a combination of using:
- spirv-opt
- RGBA16F (as opposed to e.g. RGBA8)
- framebuffer_fetch
In this CL we disable framebuffer_fetch for drivers we know have the
issue.
FIXES=[445721121]
Fix#7794
- Add a VulkanSemaphore ref-counted class to track the references
of a semamphore - i.e. in a command buffer or in a present.
- Add a VulkanSemaphoreManager class to keep a pool of
VkSempahores for better re-use.
This fixes a validation error where we were re-using a semaphore
that is associated with a command buffer while its being used
in a present (as a wait signal).
Error ris VUID-vkQueueSubmit-pSignalSemaphores-00067
* material cache: address comments
* material cache: simplify CRC32 comparison
* material cache: == if same address
* material cache: use plain type for cached crc32
Allow returning a list of supported shader languages
instead of only one.
Notify the backend which is the preferred language.
In the case of metal, the preferred language will be
the first element in the list.
This change will allow a backend to support multiple
languages as needed, in the case of the noop driver,
it will support a material with any shader languages.
* materials: introduce MaterialCache
Presently, Filament Materials are instantiated by first parsing a bunch of
read-only data from a material file, then applying a bunch of options from its
Builder before settling on a final, immutable Material object. If two different
Material instances need to be parameterized differently, e.g. setting their spec
constants independently, each has to do all of these steps independently for
each variation.
This change introduces two new concepts: MaterialDefinition, representing the
deserialized, read-only state of a material file, and MaterialCache, a
reference-counted system responsible for managing the lifetimes of
MaterialDefinitions. Now, each Material asks the cache if a MaterialDefinition
exists for the particular UUID of the data it's trying to read; if not,
MaterialCache creates a new entry transparently. If a hundred different
Materials all try to load the same material data, only one
MaterialDefinition (and its associated GPU resources) will be created.
This first PR is the least possible invasive implementation of this feature.
There are a lot of room for improvements (and more planned). For example, each
Material still manages its own compiled shader program cache, but we can easily
move this to the MaterialCache in future PRs, further enabling the planned
mutable spec constants feature.
Additionally, there's room here to add a Material::toBuilder() method, which
could take an extant material and create a Builder object from it already
parameterized with all of the same options, a la the prototype design pattern.
* material cache: key on crc32
* material cache: make materialParser private
* move RefCountedMap to utils and add unit tests
* material cache: make create functions private
* material cache: fix broken tests on iOS/web
* material cache: address more comments
The reason for this is that according to the GLES 3.0 spec, RG32UI is
guaranteed to be supported for writing, unlike RG32F.
We also use RGBA_INTEGER / UINT for readPixels() which is also a
guaranteed format.
Attempt to Fix#8762
* reorder backend methods
* add new "shared" buffer APIs to backends
We add the equivalent of GL's glMapBufferRange. The new APIs are:
- new "SHARED" flags when creating a BufferObject
- a new HwMemoryMappedBuffer handle
- mapBuffer() maps a range of the buffer to memory
- unmapBuffer() unmaps the range
- copyToMemoryMappedBuffer() is basically a deferred memcpy, where the
destination is a HwMemoryMappedBuffer and the source is a
BufferDecriptor
The actual implementation doesn't have to actually map/unmap the range
on mapBuffer/unmapBuffer. e.g. on Vulkan these method are used mostly
to set offsets (for copyToMemoryMappedBuffer) and trigger the necessary
synchronizations.
Added some basic unit tests.
* add basic support for MemoryMappedBuffer in vk and metal
we implement copyToMemoryMappedBuffer() by calling updateBufferObject(),
which is enough to satisfy the API (And pass the tests).
This saves a CString copy on the backend side and this forces the
frontend to make a copy explicitly.
In theory the CString should now ever be copied just once.
- Allow for presets to override selected models when presented
in order.
- Add 'gltf' for model search path
- Add a few simple gltf models to the 'base' preset
- Improve UI so that missing tests do not generate any html
bits.
- Add documentation on using the viewer
- Add renderdiff documentation to the project webpage.
RDIFF_BRANCH=pf/renderdiff-enable-webgpu
- The vk readPixels relies heavily on DataReshaper to transform
the output into the client's requested format. We make
additions to the DataReshaper to address previously unavailable
features:
- A copy for half floats - Assuming input and output are
both half floats. We just do memcpy.
- Reshaping with respect to PixelBufferDescriptor's top and
left parameters.
- On the test side, we do a bit of clean-up and add the ability
to export image correctly when the PBD has dimensions different
from the readRect and/or non-zero offsets.
- Also re-enable two LoadImage tests.
Make sure that the rendertarget dimensions matches the texture
dimensions. Update the expected image for the test.
Also fixed usage, rendertarget parameters to make sure vk does
not have any validation errors.
Add a way to show the difference between two rendererd image.
This is a convenience feature to see the differences between
backends.
Refactor the ExpandedFailedResult to use this new view.
