Uses the utility added in https://github.com/flutter/engine/pull/51361
I counted the removal of 58 static casts. There was one addition made to the original utility however. Vulkan HPP was promoting all enums to its own mask type. This in itself is problematic but we got away with it because there was no one else doing this kind of promotion. Till we added our own utility. To avoid polluting the namespace with methods that may cause ambiguity, enums that are masks must explicitly be marked as maskable with `IMPELLER_ENUM_IS_MASK` in the `impeller` namespace.
No change in functionality.
Part of https://github.com/flutter/flutter/issues/144617
Adds MemoryBudgetUsageMB which includes the MB of VMA allocated GPU and host memory, approximately per frame. This will be recorded in the devicelab and used to track how much memory pressure we're creating.
Split out from https://github.com/flutter/engine/pull/51187 since that was reverted (and doing big changes is a bad idea anyway).
Various cleanups to Vulkan allocator implementation:
1. Fixes https://github.com/flutter/flutter/issues/137454
2. Fold device transient cap check into allocator.
3. adds debug tracking for total memory usage in MB (a followup change needs to be made to driver to plumb it through)
4. Small cleanups to mock vulkan so an allocator can be created from it.
5. depth/stencil shouldn't be input attachments.
Part of https://github.com/flutter/flutter/issues/144617
Deletes usage in Scene of this code, which was the only non-test location that used it.
This code imports Skia based code to decompress PNG images, and it's not clear when we'd need it outside of tests at this point.
It is otherwise a pretty thin wrapper around a texture allocation.
Fixes https://github.com/flutter/flutter/issues/143194
The backend specific sampler libraries hold a strong reference to the native sampler objects and never clear this cache. As a result of this, we don't theoretically need rendering commands to increment a shared_ptr ref count - instead the sampler library can provide the Sampler object as a const ref and guarantee that it continues to be valid.
This allows us to reduce the amount of refcount ops for commands that use samplers.
Additionally, the sampler library uses nullptr as a sentinel for failing to construct a sampler object. Since sampler already has an isValid member that is checked - we can replace this with a specific invalid object subtype.
This was from a previous attempt to reduce allocation pressure using per-thread pools, but they don't actually work since as soon as a pool needs to allocate a new block we end up locking on some vk device calls,
The original change was reverted as it broke the GPU tracer reset logic. The previous logic assumed that the first started command buffer would also be the first submitted command buffer. With the direct encoding, this is no longer the case - so we shift the logic so that we reset query pools once at startup and then after the queries are finished being recorded.
This might actually be better in general since we should be doing less work in the frame workload.
Reverts flutter/engine#49780
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
Part of https://github.com/flutter/flutter/issues/140804
Rather than using impeller::Command, the impeller::RenderPass records most state directly into the Vulkan command buffer. This should remove allocation/free overhead of the intermediary structures and make further improvements to the backend even easier. This required a number of other changes to the renderer:
1. The render pass holds a strong ptr to the context. This helps avoid locking continually while encoding, which is quite slow.
2. barriers need to be encoded on the _producing_ side, and not the consuming side. This is because we'll actually run the consuming code before the producing code. i.e. we transition to shader read at the end of a render pass instead of when binding.
3. I've updated the binding code to also provide the descriptor type so that we don't need to look it up from the desc. set.
4. I added a test render pass class that records commands.
Part of https://github.com/flutter/flutter/issues/140804
Rather than using impeller::Command, the impeller::RenderPass records most state directly into the Vulkan command buffer. This should remove allocation/free overhead of the intermediary structures and make further improvements to the backend even easier. This required a number of other changes to the renderer:
1. The render pass holds a strong ptr to the context. This helps avoid locking continually while encoding, which is quite slow.
2. barriers need to be encoded on the _producing_ side, and not the consuming side. This is because we'll actually run the consuming code before the producing code. i.e. we transition to shader read at the end of a render pass instead of when binding.
3. I've updated the binding code to also provide the descriptor type so that we don't need to look it up from the desc. set.
4. I added a test render pass class that records commands.
Now that the HostBuffer isn't implementing Buffer, there is really no reason to have a Buffer/DeviceBuffer split. make BufferViews use a DeviceBuffer, and remove the data ptr from buffer views (as we can always reach into the device buffer).
Makes some other cleanups too, since we always use a std::shared_ptr<DeviceBuffer>, then we can eliminated the shared_from_this call for AsBufferView by making this a static method.
Fixes https://github.com/flutter/flutter/issues/122823
Fixes https://github.com/flutter/flutter/issues/129659
Fixes https://github.com/flutter/flutter/issues/123741
This patch makes runtime stage/fragment program stuff work on Vulkan for Android.
It will need flutter/flutter#140976 for that to become a reality for flutter_tools users.
Compiling with relaxed Vulkan semantics still has an issue: shaders that use `sampler2D` with an explicitly set `location` on the `layout` will fail to compile with an error documented in https://github.com/flutter/flutter/issues/141219.
I think there might still be some issues with fragment programs on Vulkan, but this should at least be a good starting point and unblocks ink_sparkle.frag usage in the framework.
I've deleted some runtime_stage related code that would never get used - for example, enum related code that indicates we might support a bunch of data types that we do not and probably never will support in this API.
Reland of https://github.com/flutter/engine/pull/49505
---
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
Reverts flutter/engine#49505
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
part of https://github.com/flutter/flutter/issues/140804
We can't use the existing host buffer abstraction as that requires us to collect all allocations up front. By itself, this isn't sufficient for #140804 , because we'll need a way to mark ranges as dirty and/or flush if we don't have host coherent memory. But by itself this change should be beneficial as we'll create fewer device buffers and should do less allocation in general.
The size of the device buffers is 1024 Kb, somewhat arbitrarily chosen.
This is part of the work towards supporting OpenGLES and Vulkan for runtime stage shaders.
Removes some redundant work we had around SkSL. Now only bundles the shaders we actually ask for from the command line.
@bdero, we should figure out if this is the right approach for flutter_gpu.
With this change, the IPLR format goes from having a root table of shader related information to a root table of shader information per `sksl`, `metal`, `opengles`, and `vulkan` platforms.
This may end up allowing us to revert https://github.com/flutter/engine/pull/47278, but I'm not sure I understand all the implications of that at this point.
I have run some but not all tests locally.
The hash function we use for pipeline hashncash is actually pretty slow. Since all of the properties we hash on fit in 64 bits, we can compute a hash value directly. From local benchmarking this is about twice as fast, which still leaves quite a bit of room for future improvement (faster hashmap? not using a hashmap at all?)
Places the binding data in a vector, since they key was only meaningful on metal but not used anywhere. I don't think that we need to specificially handle the case where our own contents bind the same contents multiple times, but interested to discuss if folks disagree.
Support framebuffer fetch on devices that have the extension VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS which gives us a fairly easy way to add subpass self dependencies.
Part of https://github.com/flutter/flutter/issues/120223
Placing the vertex buffer on the binding object meant that we were actually paying 2x the size cost for it (one for vertex bindings, one for fragment bindings). By moving this object onto command itself, we reduce the size and avoid spliting up the command state in a weird way.
Also updates most of the contents to prefer moving the VertexBuffer.
Towards https://github.com/flutter/flutter/issues/133417#issuecomment-1839273553
I'll request a test exemption for this as it's a semantics-only refactor.
There are still a bunch of other forward declares in Impeller that make things confusing for tooling, but some of those will require less trivial changes to interfaces.
Removes unused or redundant overloads and fixes the IsEmpty method on Size to be both simpler (2 comparisons vs. 4) and NaN-aware. Rect automatically uses the new code via delegation to the Size object.
This allows backdrop filters to work with GLES and MSAA.
The swap implementation was only swapping out the resolve texture. But with implicit msaa resolve, the resolve texture and msaa texture are the same - so both need to be swapped.
Fixes https://github.com/flutter/flutter/issues/137301
Sprinkle cstdint everywhere that it's used. Unblocks the next impeller-cmake bump.
Ran into include issues during the build for the most recent impeller-cmake bump: https://github.com/bdero/impeller-cmake/pull/20
Going to add an optional libcxx STL build to help avoid stuff like this later (in the AAOS action items).
Really not convinced this is easier to read but maybe I just need to get used to it. Besides, good to just stick to the style guide uniformly.
Followup from https://github.com/flutter/engine/pull/47278#discussion_r1371971876
Can do this for the rest of the engine and remove the macros if this is fine.
Add docstrings for the capabilities. Include examples/extra detail for the more confusing concepts.
Also renames a couple of capabilities for consistency with format terminology:
* SupportsDecalTileMode -> SupportsDecalSamplerAddressMode
* SupportsMemorylessTextures -> SupportsDeviceTransientTextures
PR is built on https://github.com/flutter/engine/pull/45240 (waiting for tree to reopen).
The metal backend is the only backend that doesn't treat binding the vertex buffer specially. For the GLES and Vulkan backend, we can instead pull it out of the cmd map entirely.
This will make it easier to partially inline the map into the bindings object.
https://github.com/flutter/flutter/issues/133199
