As far as I can tell, 32 VBOs is min-spec in D3D11/12, and ANV exposes 31? Why does ANV expose less than that?
While this particular PSO can probably be worked around, I'd like to understand why 31 is a limit.
32 has indeed been the D3D requirement since D3D10.1.
FWIW, DXVK dodges this issue by compacting VBO binding ranges per PSO, but doing that in vkd3d-proton would potentially force us to do a lot of redundant vertex buffer re-binding any time the active PSO changes, which isn't great.
It also breaks DGC since VBO bindings are encoded there too and trying to work around by emitting different indirect layouts is just way too complicated.
I'll try a workaround, and just fail for cases where DGC goes beyond the limit, which I don't think any content ever will hit (updating VBO 31 in EI is insanity).
As far as I can tell, 32 VBOs is min-spec in D3D11/12, and ANV exposes 31? Why does ANV expose less than that? While this particular PSO can probably be worked around, I'd like to understand why 31 is a limit.
git-blame points to https://gitlab.freedesktop.org/mesa/mesa/-/commit/c46d3acf0e3624f110c6d49f3eeef70fa1795855 which has a good explanation of what's motivating the current limit. I've reached out to Ken to see how hard it'd be to rework things to increase the vertex input binding limit, but I get the sense from his writeup that there's a non-trivial effort involved.
As far as I can tell, 32 VBOs is min-spec in D3D11/12, and ANV exposes 31? Why does ANV expose less than that? While this particular PSO can probably be worked around, I'd like to understand why 31 is a limit.
Because on Gfx9 we had to burn one to feed the gl_BaseVertex, gl_BaseInstance & gl_DrawID. we might be able to reclaim it on Gfx11+
Ken expanded on Lionel's comment above to say we should be able to increase the MAX_VBS for Gen11 (Ice Lake) and above. I'll put together an MR. This should avoid the assert on any platform this workload can reasonably expected to run.
I'll close this issue for now; feel free to re-open if it's a good place to track vertex input binding WAs in vkd3d-proton, but I'd guess that's a low ROI activity at this point.
If it can be fixed on ANV's end this isn't super exciting to work on, indeed.
MR is reviewed : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35376
Sadly only Gfx11+
If it can be fixed on ANV's end this isn't super exciting to work on, indeed.
I'm generally of a "fail loud, fail early" mindset, so I wouldn't have minded if vkd3d had died with an error because the D3D spec requirements couldn't be met with the given Vulkan implementation. This workload seemed to survive having a VBO dropped on the floor, but it seems likely that workloads could manifest the issue as hard-to-debug misrendering.
Even a warning would be helpful, though those tend to get lost in the noise.
MR is reviewed : gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35376
Sadly only Gfx11+
Will this be backported to mesa-stable?
Nothing extracted yet.
Launching the Final Fantasy XVI demo on Intel BMG with a Mesa debug build triggers an assert because the specified binding is greater than the maximum available vertex buffers. This behavior is documented in the attached steam-237800.log file.
Per the Vulkan spec, the "binding must be less than VkPhysicalDeviceLimits::maxVertexInputBindings."
vulkaninforeports the maxVertexInputBindings for this BMG platform is 31. Debugging game in gdb (using MR 35324 to attach) shows the binding number that triggers the assert is 31; details in vbs_max_assert_debug.log.Adding validation to Mesa that returns
VK_ERROR_VALIDATION_FAILED_EXTinstead of asserting causes vkd3d-proton to dump a lot of information that confirms the binding number is coming from vkd3d-proton; seesteam-273800_validation.log. The game eventually loads the main menu with this additional validation, but crashes with a message in what appears to be Japanese when attempting to launch a new game.As far as I can tell, the workload is not conforming to the Vulkan spec in this case. I've looked around the vkd3d-proton codebase a little but haven't identified the source for this seemingly out-of-spec binding number.
This behavior does not manifest with other titles on the same platform. I tried Witcher 3 and Oblivion Remastered.
System information
Log files