kc3-lang/angle/src/libANGLE/renderer/vulkan/README.md
-
Show log
Commit
-
Hash : 3f0c4a56
Author :
Date : 2019-01-10T10:20:35
Vulkan: Faster state transitions. Implements a transition table from Pipeline Cache entry to state change neighbouring Pipeline Cache entries. We use a 64-bit mask to do a quick scan over the pipeline desc. This ends up being a lot faster than doing a full hash and memcmp over the pipeline description. Note that there could be future optimizations to this design. We might keep a hash map of the pipeline transitions instead of a list. Or use a sorted list. This could speed up the search when there are many transitions for cache entries. Also we could skip the transition table and opt to do a full hash when there are more than a configurable number of dirty states. This might be a bit faster in some cases. Likely this will be something we can add performance tests for in the future. Documentation is also added in a README file for the Vulkan back end. This will be extended over time. Improves performance about 30-35% on the VBO state change test. Bug: angleproject:3013 Change-Id: I793f9e3efd8887acf00ad60e4ac2502a54c95dee Reviewed-on: https://chromium-review.googlesource.com/c/1369287 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
ANGLE: Vulkan Back-end
ANGLE’s Vulkan back-end implementation lives in this folder.
Vulkan is an explicit graphics API. It has a lot in common with other explicit APIs such as Microsoft’s D3D12 and Apple’s Metal. Compared to APIs like OpenGL or D3D11 explicit APIs can offer a number of significant benefits:
- Lower API call CPU overhead.
- A smaller API surface with more direct hardware control.
- Better support for multi-core programming.
- Vulkan in particular has open-source tooling and tests.
Back-end Design
The RendererVk is a singleton. RendererVk owns shared global resources like the
VkDevice,
VkQueue, the
Vulkan format tables and internal Vulkan shaders. The back-end
creates a new ContextVk instance to manage each allocated OpenGL Context. ContextVk
processes state changes and handles action commands like glDrawArrays and glDrawElements.
Fast OpenGL State Transitions
Typical OpenGL programs issue a few small state change commands between draw call commands. We want the typical app’s use case to be as fast as possible so this leads to unique performance challenges.
Vulkan in quite different from OpenGL because it requires a separate compiled VkPipeline for each state vector. Compiling VkPipelines is multiple orders of magnitude slower than enabling or disabling an OpenGL render state. To speed this up we use three levels of caching when transitioning states in the Vulkan back-end.
The first level is the driver’s VkPipelineCache. The driver cache reduces pipeline recompilation time significantly. But even cached pipeline recompilations are orders of manitude slower than OpenGL state changes.
The second level cache is an ANGLE-owned hash map from OpenGL state vectors to compiled pipelines. See GraphicsPipelineCache in vk_cache_utils.h. ANGLE’s GraphicsPipelineDesc class is a tightly packed 256-byte description of the current OpenGL rendering state. We also use a xxHash for the fastest possible hash computation. The hash map speeds up state changes considerably. But it is still significantly slower than OpenGL implementations.
To get best performance we use a transition table from each OpenGL state vector to neighbouring
state vectors. The transition table points from GraphicsPipelineCache entries directly to
neighbouring VkPipeline objects. When the application changes state the state change bits are
recorded into a compact bit mask that covers the GraphicsPipelineDesc state vector. Then on the next
draw call we scan the transition bit mask and compare the GraphicsPipelineDesc of the current state
vector and the state vector of the cached transition. With the hash map we compute a hash over the
entire state vector and then do a 256-byte memcmp to guard against hash collisions. With the
transition table we will only compare as many bytes as were changed in the transition bit mask. By
skipping the expensive hashing and memcmp we can get as good or faster performance than native
OpenGL drivers.
Note that the current design of the transition table stores transitions in an unsorted list. If applications map from one state to many this will slow down the transition time. This could be improved in the future using a faster look up. For instance we could keep a sorted transition table or use a small hash map for transitions.
Source
-
src/libANGLE/renderer/vulkan/README.md
-
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
# ANGLE: Vulkan Back-end ANGLE's Vulkan back-end implementation lives in this folder. [Vulkan](https://www.khronos.org/vulkan/) is an explicit graphics API. It has a lot in common with other explicit APIs such as Microsoft's [D3D12](https://docs.microsoft.com/en-us/windows/desktop/direct3d12/directx-12-programming-guide) and Apple's [Metal](https://developer.apple.com/metal/). Compared to APIs like OpenGL or D3D11 explicit APIs can offer a number of significant benefits: * Lower API call CPU overhead. * A smaller API surface with more direct hardware control. * Better support for multi-core programming. * Vulkan in particular has open-source tooling and tests. ## Back-end Design The [RendererVk](RendererVk.cpp) is a singleton. RendererVk owns shared global resources like the [VkDevice](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkDevice.html), [VkQueue](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkQueue.html), the [Vulkan format tables](vk_format_utils.h) and [internal Vulkan shaders](shaders). The back-end creates a new [ContextVk](ContextVk.cpp) instance to manage each allocated OpenGL Context. ContextVk processes state changes and handles action commands like `glDrawArrays` and `glDrawElements`. ### Fast OpenGL State Transitions Typical OpenGL programs issue a few small state change commands between draw call commands. We want the typical app's use case to be as fast as possible so this leads to unique performance challenges. Vulkan in quite different from OpenGL because it requires a separate compiled [VkPipeline](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkPipeline.html) for each state vector. Compiling VkPipelines is multiple orders of magnitude slower than enabling or disabling an OpenGL render state. To speed this up we use three levels of caching when transitioning states in the Vulkan back-end. The first level is the driver's [VkPipelineCache](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkPipelineCache.html). The driver cache reduces pipeline recompilation time significantly. But even cached pipeline recompilations are orders of manitude slower than OpenGL state changes. The second level cache is an ANGLE-owned hash map from OpenGL state vectors to compiled pipelines. See [GraphicsPipelineCache](https://chromium.googlesource.com/angle/angle/+/225f08bf85a368f905362cdd1366e4795680452c/src/libANGLE/renderer/vulkan/vk_cache_utils.h#498) in [vk_cache_utils.h](vk_cache_utils.h). ANGLE's [GraphicsPipelineDesc](https://chromium.googlesource.com/angle/angle/+/225f08bf85a368f905362cdd1366e4795680452c/src/libANGLE/renderer/vulkan/vk_cache_utils.h#244) class is a tightly packed 256-byte description of the current OpenGL rendering state. We also use a [xxHash](https://github.com/Cyan4973/xxHash) for the fastest possible hash computation. The hash map speeds up state changes considerably. But it is still significantly slower than OpenGL implementations. To get best performance we use a transition table from each OpenGL state vector to neighbouring state vectors. The transition table points from GraphicsPipelineCache entries directly to neighbouring VkPipeline objects. When the application changes state the state change bits are recorded into a compact bit mask that covers the GraphicsPipelineDesc state vector. Then on the next draw call we scan the transition bit mask and compare the GraphicsPipelineDesc of the current state vector and the state vector of the cached transition. With the hash map we compute a hash over the entire state vector and then do a 256-byte `memcmp` to guard against hash collisions. With the transition table we will only compare as many bytes as were changed in the transition bit mask. By skipping the expensive hashing and `memcmp` we can get as good or faster performance than native OpenGL drivers. Note that the current design of the transition table stores transitions in an unsorted list. If applications map from one state to many this will slow down the transition time. This could be improved in the future using a faster look up. For instance we could keep a sorted transition table or use a small hash map for transitions.