If there is heavy reliance on StructuredBuffer or ByteAddressBuffer loads, this is somewhat expected. There is currently no good way to implement these efficiently in Vulkan for hardware that has alignment restrictions on vectorized loads, we can't really make any assumptions about the data structure being loaded, and BDA isn't a good use case for this either since we'd have to manually implement bounds-checking and would potentially hit even slower paths on certain hardware.
fwiw, we are able to vectorize a bunch of stuff in DXIL, but DXBC is basically a non-starter due to its non-SSA formulation.
Nothing extracted yet.
Hi Community
We discovered that some compute shader show bad performance after vkd3d translation.
Here is the detail.
Strange Brigade support two version: dx12 and vulkan. But the dx12 benchmark score is 70%~80% of vulkan. (Both on linux)
With "INTEL_MEASURE=draw,file=/tmp/mesure.csv", mesa profiling result shows that there is a big difference in compute shader. (375us vs 184us)
According to the perfetto result, the compute operation blocks following draw call. So the performance can be improved if we can optimize compute here.
Here is the link about compute shader of dx12_to_vulkan and native vulkan.
https://drive.google.com/drive/folders/1HoVMaDrTl4pwzA4qS2slymr2-BG0Cwq8
The amount of Load and Store OP is as below. And can find that Load operation is extremely high in Dx12->vulkan.
We suspect that it's related to the below code in 4f003e374340035c.spv.glsl
According to https://themaister.net/blog/2021/11/07/my-personal-hell-of-translating-dxil-to-spir-v-part-3/ , maybe related to more levels of indirections of loads and un-guaranteed alignments, so component loads are unrolled mostly to scalar loads?