Commits on Source (12)
-
Conor McCarthy authored
We currently create statically sized descriptor pools, shared among different descriptor types. Once we're unable to allocate a descriptor set from a pool, we create a new pool. The unfortunate but predictable consequence is that when we run out of descriptors of one type, we waste any unallocated descriptors of the other types. Dynamically adjusting the pool sizes could mitigate the issue, but it seems non-trivial to handle all the edge cases, particularly in situations where the descriptor count ratios change significantly between frames. Instead, by storing only a single vkd3d descriptor type in each Vulkan descriptor set we're able to create separate descriptor pools for each vkd3d descriptor type, which also avoids the issue. The main drawback of using separate descriptor sets for each descriptor type is that we can no longer pack all bounded descriptor ranges into a single descriptor set, potentially leaving fewer descriptor sets available for unbounded ranges. That seems worth it, but we may end up having to switch to a more complicated strategy if this ends up being a problem on Vulkan implementations with a very limited number of available descriptor sets.
-
Conor McCarthy authored
-
Conor McCarthy authored
-
Conor McCarthy authored
-
Conor McCarthy authored
-
Conor McCarthy authored
-
Henri Verbeet authored
-
Conor McCarthy authored
Now that our Vulkan descriptor sets contain only a single vkd3d descriptor type, we're able to create descriptor pools containing only a single vkd3d descriptor type as well. This avoids wasting unallocated descriptors of one type when we run out of descriptors of another type.
-
Conor McCarthy authored
Creating a pool of 16k descriptors is wasteful if an allocator only uses a fraction of them, so start at 1k and double for each subsequent allocation until 16k is reached.
-
Giovanni Mascellani authored
Currently, when using Vulkan heaps, we create descriptor set layouts with as many descriptors as allowed by the Vulkan implementation limits. For some implementations this can mean hundreds of millions of descriptors or more, which is wasteful, given that even on the best resource binding tier Direct3D 12 applications should not expect to have more than a million usable descriptors. Recently this began being a problem, because since Mesa 24.2.7 the Intel driver advertises more than 200 million descriptors, but pipeline compilation takes linear RAM in the number of descriptors declared in the pipeline layout. This means that compiling even a simple shader requires 10-20 GB of RAM. In order to avoid using too much memory, with this commit we clamp the number of descriptors declared in the set layouts to how many we actually need to guarantee tier 3 resource binding support.
-
Giovanni Mascellani authored
-
Giovanni Mascellani authored
Showing
- libs/vkd3d-shader/ir.c 24 additions, 1 deletionlibs/vkd3d-shader/ir.c
- libs/vkd3d/command.c 187 additions, 84 deletionslibs/vkd3d/command.c
- libs/vkd3d/device.c 20 additions, 38 deletionslibs/vkd3d/device.c
- libs/vkd3d/state.c 144 additions, 93 deletionslibs/vkd3d/state.c
- libs/vkd3d/vkd3d_private.h 49 additions, 14 deletionslibs/vkd3d/vkd3d_private.h
This diff is collapsed.