[PR #147] [MERGED] video_core: Add constant buffer support #1339

Closed
opened 2026-02-27 21:12:09 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/147
Author: @raphaelthegreat
Created: 5/26/2024
Status: Merged
Merged: 5/26/2024
Merged by: @raphaelthegreat

Base: mainHead: const-buf


📝 Commits (1)

  • a19b03d video_core: Add constant buffer support

📊 Changes

26 files changed (+396 additions, -57 deletions)

View changed files

📝 src/common/logging/backend.cpp (+1 -0)
📝 src/core/libraries/kernel/libkernel.cpp (+1 -0)
📝 src/core/libraries/kernel/memory_management.cpp (+5 -0)
📝 src/core/libraries/kernel/memory_management.h (+1 -0)
📝 src/core/memory.cpp (+12 -1)
📝 src/core/memory.h (+2 -0)
📝 src/shader_recompiler/backend/spirv/emit_spirv_context_get_set.cpp (+38 -0)
📝 src/shader_recompiler/backend/spirv/emit_spirv_instructions.h (+9 -0)
📝 src/shader_recompiler/backend/spirv/spirv_emit_context.cpp (+48 -7)
📝 src/shader_recompiler/backend/spirv/spirv_emit_context.h (+10 -2)
📝 src/shader_recompiler/frontend/translate/translate.cpp (+4 -1)
📝 src/shader_recompiler/frontend/translate/translate.h (+3 -0)
📝 src/shader_recompiler/frontend/translate/vector_memory.cpp (+31 -0)
📝 src/shader_recompiler/ir/ir_emitter.cpp (+20 -0)
📝 src/shader_recompiler/ir/ir_emitter.h (+5 -0)
📝 src/shader_recompiler/ir/opcodes.inc (+7 -0)
📝 src/shader_recompiler/ir/passes/resource_tracking_pass.cpp (+87 -37)
📝 src/shader_recompiler/ir/reg.h (+11 -0)
📝 src/shader_recompiler/recompiler.cpp (+2 -1)
📝 src/shader_recompiler/runtime_info.h (+30 -2)

...and 6 more files

📄 Description

Next step after previous PR was to add constant buffers to shader recompiler. The goal of the design is to hopefully be able to handle more advanced cases like bindless or when sharps are nested behind many constant load operations. So in general, cases where sharp location is difficult to know upfront. When emitting IR we the recompiler is not aware of the sharp location. The emitted instruction will have a handle that is the SGPR of the loaded sharp and some additional arguments that we can derive without needing to read the sharp.

Then once IR has been emitted we run a resource tracking pass whose job is to follow constant loads and figure out where the sharp is located in memory. After it's loaded we patch the buffer instruction, replacing the handle with the binding index in the buffer resource array and compute the full address. Also it will check if the sharp address is aligned to UBO requirement of the host and fallback to SSBO if not. On SPIR-V side for simplicity buffers are arrays of floats (will also be uint in the future), so it can handle any provided address it has been given (not all loads can be expressed as a single composite array load, especially 3 dword loads whose offset is not 3 dword aligned). In the future I would like to experiment with attempting to reconstruct the struct layout of the UBO/SSBO.

For vulkan side, resources use push descriptors for the simplicity. I think some AMD drivers have broken push descriptors though so a fallback back with normal descriptor writes can be implemented as well without too much hassle.

#version 450
#extension GL_EXT_scalar_block_layout : require

layout(set = 0, binding = 0, scalar) uniform vs_cbuf_block_f32
{
    float data[16];
} c0;

layout(location = 0) in vec4 vs_in_attr0;
layout(location = 0) out vec4 out_attr0;

void main()
{
    uint _57 = uint(gl_VertexIndex) * 4u;
    vec4 _70 = vec4(c0.data[_57 + 0u], c0.data[_57 + 1u], c0.data[_57 + 2u], c0.data[_57 + 3u]);
    gl_Position.x = vs_in_attr0.x;
    gl_Position.y = vs_in_attr0.y;
    gl_Position.z = vs_in_attr0.z;
    gl_Position.w = vs_in_attr0.w;
    out_attr0.x = _70.x;
    out_attr0.y = _70.y;
    out_attr0.z = _70.z;
    out_attr0.w = _70.w;
}

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/shadps4-emu/shadPS4/pull/147 **Author:** [@raphaelthegreat](https://github.com/raphaelthegreat) **Created:** 5/26/2024 **Status:** ✅ Merged **Merged:** 5/26/2024 **Merged by:** [@raphaelthegreat](https://github.com/raphaelthegreat) **Base:** `main` ← **Head:** `const-buf` --- ### 📝 Commits (1) - [`a19b03d`](https://github.com/shadps4-emu/shadPS4/commit/a19b03d5ede28ba328952b414b34c7844b87e19d) video_core: Add constant buffer support ### 📊 Changes **26 files changed** (+396 additions, -57 deletions) <details> <summary>View changed files</summary> 📝 `src/common/logging/backend.cpp` (+1 -0) 📝 `src/core/libraries/kernel/libkernel.cpp` (+1 -0) 📝 `src/core/libraries/kernel/memory_management.cpp` (+5 -0) 📝 `src/core/libraries/kernel/memory_management.h` (+1 -0) 📝 `src/core/memory.cpp` (+12 -1) 📝 `src/core/memory.h` (+2 -0) 📝 `src/shader_recompiler/backend/spirv/emit_spirv_context_get_set.cpp` (+38 -0) 📝 `src/shader_recompiler/backend/spirv/emit_spirv_instructions.h` (+9 -0) 📝 `src/shader_recompiler/backend/spirv/spirv_emit_context.cpp` (+48 -7) 📝 `src/shader_recompiler/backend/spirv/spirv_emit_context.h` (+10 -2) 📝 `src/shader_recompiler/frontend/translate/translate.cpp` (+4 -1) 📝 `src/shader_recompiler/frontend/translate/translate.h` (+3 -0) 📝 `src/shader_recompiler/frontend/translate/vector_memory.cpp` (+31 -0) 📝 `src/shader_recompiler/ir/ir_emitter.cpp` (+20 -0) 📝 `src/shader_recompiler/ir/ir_emitter.h` (+5 -0) 📝 `src/shader_recompiler/ir/opcodes.inc` (+7 -0) 📝 `src/shader_recompiler/ir/passes/resource_tracking_pass.cpp` (+87 -37) 📝 `src/shader_recompiler/ir/reg.h` (+11 -0) 📝 `src/shader_recompiler/recompiler.cpp` (+2 -1) 📝 `src/shader_recompiler/runtime_info.h` (+30 -2) _...and 6 more files_ </details> ### 📄 Description Next step after previous PR was to add constant buffers to shader recompiler. The goal of the design is to hopefully be able to handle more advanced cases like bindless or when sharps are nested behind many constant load operations. So in general, cases where sharp location is difficult to know upfront. When emitting IR we the recompiler is not aware of the sharp location. The emitted instruction will have a handle that is the SGPR of the loaded sharp and some additional arguments that we can derive without needing to read the sharp. Then once IR has been emitted we run a resource tracking pass whose job is to follow constant loads and figure out where the sharp is located in memory. After it's loaded we patch the buffer instruction, replacing the handle with the binding index in the buffer resource array and compute the full address. Also it will check if the sharp address is aligned to UBO requirement of the host and fallback to SSBO if not. On SPIR-V side for simplicity buffers are arrays of floats (will also be uint in the future), so it can handle any provided address it has been given (not all loads can be expressed as a single composite array load, especially 3 dword loads whose offset is not 3 dword aligned). In the future I would like to experiment with attempting to reconstruct the struct layout of the UBO/SSBO. For vulkan side, resources use push descriptors for the simplicity. I think some AMD drivers have broken push descriptors though so a fallback back with normal descriptor writes can be implemented as well without too much hassle. ```glsl #version 450 #extension GL_EXT_scalar_block_layout : require layout(set = 0, binding = 0, scalar) uniform vs_cbuf_block_f32 { float data[16]; } c0; layout(location = 0) in vec4 vs_in_attr0; layout(location = 0) out vec4 out_attr0; void main() { uint _57 = uint(gl_VertexIndex) * 4u; vec4 _70 = vec4(c0.data[_57 + 0u], c0.data[_57 + 1u], c0.data[_57 + 2u], c0.data[_57 + 3u]); gl_Position.x = vs_in_attr0.x; gl_Position.y = vs_in_attr0.y; gl_Position.z = vs_in_attr0.z; gl_Position.w = vs_in_attr0.w; out_attr0.x = _70.x; out_attr0.y = _70.y; out_attr0.z = _70.z; out_attr0.w = _70.w; } ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-02-27 21:12:09 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/shadPS4#1339
No description provided.