niansa-misc/dxvk
1
0
Fork 0
mirror of https://github.com/doitsujin/dxvk.git synced 2025-03-06 20:58:37 +01:00
Code Issues Projects Releases Packages Wiki Activity

Updated Developer guidelines (markdown)

Philip Rebohle 2025-03-02 02:22:27 +01:00
parent 5e5761d3ec
commit 3be71b5ea6
1 changed files with 6 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
Developer-guidelines.md

@ -34,6 +34,7 @@ Note that this page is written for DXVK 2.6 and later. Older versions may behave
### CPU access
- For mapped resources created with `D3D11_USAGE_DYNAMIC`, always write full cache lines for optimal CPU performance. DXVK will generally allocate these resources in host-visible video memory, especially on systems with Resizeable BAR enabled.
- **Never** perform a CPU read from a resource that was created without the `D3D11_CPU_ACCESS_READ` flag. In the worst case, these resources are allocated in VRAM and have to be read back over PCI-E, which can very quickly become an extreme bottleneck. This also applies to inefficient write patterns such as keeping multiple partially written cache lines in flight.
- Do not use large textures with `D3D11_USAGE_DYNAMIC` and non-zero bind flags. Both GPU and CPU access to these resources will be inefficient.
- Prefer `D3D11_USAGE_DEFAULT` textures and use `UpdateSubresource` for updates.
- Textures with no bind flags as well as `D3D11_USAGE_STAGING` resources are unaffected by this.
@ -44,7 +45,9 @@ Note that this page is written for DXVK 2.6 and later. Older versions may behave
- Do not create textures with `DXGI_FORMAT_R32G32B32_*`. Vulkan driver support for these formats is limited.
**Note:** This does *not* apply to using these formats for vertex buffers or buffer views.
- Avoid `MAP_WRITE` on staging resources that are still in use by the GPU. DXVK will try to avoid stalls by creating a local copy of the resource, but this comes at the cost of both CPU performance and memory usage.
- **NEVER** perform a CPU read from a resource that was created without the `D3D11_CPU_ACCESS_READ` flag. In the worst case, these resources are allocated in VRAM and have to be read back over PCI-E, which can very quickly become a major bottleneck. This also applies to inefficient write patterns such as multiple partially written cache lines.
- Consider calling `Flush` after writing one or more staging resources that will be read back on the CPU, or after issuing a sequence of queries.
This is not strictly required and DXVK has heuristics to submit shortly after such an operation anyway, however explicitly calling `Flush` may lead to more consistent read-back latency and more efficient submission patterns, especially on tiling GPUs.
- Avoid calling `Flush` more than 2-3 times per frame.
## Commands
- Use the `StartIndexLocation` and `BaseVertexLocation` parameters for draw calls instead of re-binding the same vertex or index buffers with different offsets.
@ -70,8 +73,8 @@ Note that this page is written for DXVK 2.6 and later. Older versions may behave
- `Set*Shader`.
- `IASetInputLayout`.
- `IASetPrimitiveTopology`.
- `OMSetBlendState` if the blend state object or the sample mask change. Changing the blend factor is cheaper.
- `OMSetDepthStencilState` if the depth-stencil state object changes. Changing the stencil reference is cheaper.
- `OMSetBlendState` if the blend state object or the sample mask change. Changing the blend factor is cheap.
- `OMSetDepthStencilState` if the depth-stencil state object changes. Changing the stencil reference is cheap.
- `RSSetState` if depth bias enablement changes.
- For rasterizer states, **avoid** setting `FillMode` to `D3D11_FILL_WIREFRAME`. Doing so forces us to compile Vulkan pipelines at draw time, which may cause stutter.