You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,15 @@ For those who don't want to build from source, there are few ways to get working
16
16
- For Android, each SDK tag will have binaries to download (example: [vulkan-sdk-1.3.280.0 tag](https://github.com/KhronosGroup/Vulkan-ValidationLayers/releases/tag/vulkan-sdk-1.3.280.0))
17
17
- Every change applied to the main branch runs through GitHub action and will [produce artifacts](https://github.com/KhronosGroup/Vulkan-ValidationLayers/actions?query=branch%3Amain) of the latest commit.
18
18
19
+
## Ways to enable the layer
20
+
21
+
* Use [*Vulkan Configurator*](https://www.lunarg.com/introducing-the-new-vulkan-configurator-vkconfig/)
22
+
* Set environment variables
23
+
* Windows `set VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation`
24
+
* Linux `export VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation`
Copy file name to clipboardExpand all lines: docs/chassis.md
+51-2Lines changed: 51 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
## Introduction
2
2
3
-
The Vulkan-ValidationLayers project has had its architecture evolve several times since it was started. Initially, validation was implemented as independent layers, which could be enabled using the vulkan loader. This design had high overhead and was difficult to test since the layers could be enabled in any order, which could cause very different behaviors.
3
+
The Vulkan-ValidationLayers project has had its architecture evolve several times since it was started. Initially, validation was implemented as independent layers, which could be enabled using the vulkan loader. This design had high overhead and was difficult to test since the layers could be enabled in any order, which could cause very different behaviors.
4
4
5
5
So all of the separate layers were combined into a single layer. The original layers were now called validation objects. A component called the chassis was made which intercepts vulkan commands and let validation objects do validation and track state. Several of the validation objects used common code to do state tracking, but since state tracking was implemented in a base class, each validation object had its own copy of the state data. This was redundant both for memory and CPU overhead.
6
6
@@ -36,7 +36,7 @@ The dispatch objects also store cached copies of device properties, enabled feat
36
36
37
37
### Handle wrapping
38
38
39
-
Validation has an option to replace ICD handles with generated handles which are not pointers and should be consistent run to run. Unfortunately this requires some state tracking to properly substitute in the correct handles when calling down to the ICD. This state is a separate subset of what is done by the state tracker.
39
+
Validation has an option to replace ICD handles with generated handles which are not pointers and should be consistent run to run. Unfortunately this requires some state tracking to properly substitute in the correct handles when calling down to the ICD. This state is a separate subset of what is done by the state tracker.
40
40
41
41
## Base validation objects
42
42
@@ -56,3 +56,52 @@ The diagram above shows the class hierarchy used for validation objects.
56
56
57
57
Some validations objects require additional state to be tracked for various state objects, such as command buffers, images and queues. When each validation type had its own state tracker, this was implemented using derived classes and factory methods for creating state objects. With the shared state tracker, specialization by inheritance is not possible. Instead, some state objects implement sub states, which can be used to store additional data. Some sub state types also provide virtual methods which can be overridden to perform actions when something happens to the state object. When this happens, the substates are called in the same order used by the dispatch objects.
58
58
59
+
## Command Buffers
60
+
61
+
`VkCommandBuffer` objects is where most of the state tracking occurs. Currently the `vvl::CommandBuffer` object is easily 3 or 4x larger then the next state object. From profiling, a lot of wall clock time is spend in `vkCmd*` calls not because they are slow, but because they will get called millions of times in real world applications.
62
+
63
+
We adopt a slightly different strategy with them, instead of using the chassis `PreCallRecord`/`PostCallRecord`, for as many spots as possible we want to funnel things through the `vvl::CommanBuffer` state object itself for recording.
64
+
65
+
What was once
66
+
67
+
```c++
68
+
// state_tracker.cpp
69
+
voidDeviceState::PostCallRecordCmdXXX() {
70
+
auto cb_state = GetWrite<CommandBuffer>(commandBuffer);
71
+
cb_state->state_a = 1;
72
+
cb_state->state_b = 2;
73
+
}
74
+
75
+
// cc_xxx.cpp
76
+
voidCoreCheck::PostCallRecordCmdXXX() {
77
+
auto cb_state = GetWrite<CommandBuffer>(commandBuffer);
78
+
const auto &cb_sub_state = core::SubState(*cb_state);
79
+
cb_state->state_c = 3;
80
+
cb_sub_state->state_d = 4;
81
+
}
82
+
```
83
+
84
+
Now turned into
85
+
86
+
```c++
87
+
voidDeviceState::PostCallRecordCmdXXX() {
88
+
auto cb_state = GetWrite<CommandBuffer>(commandBuffer); // one state lookup for command buffer
0 commit comments