Hi,
I was pleased to find that upon updating to the Android 14 preview, VK_EXT_dynamic_state + VK 1.3 were both supported. However when updating my application to take advantage of the new vertex binding call - 'bindVertexBuffers2EXT' - making use of both the dynamic stride and limit capabilities, I found that causes severe graphical corruption. Almost as if the GPU just skips some draws entirely and lets others through just fine. I can send an RDC capture or a demo app if necessary.
HW Info:
Mali-G78
Pixel 6 Pro
Driver 38.1.0
Hi again ByLaws,
We weren't able to reproduce this in a directed test so far; I wonder if there might be some more complicated interaction of things which cause the issue.
Is it possible to share a reproducer (APK / RenderDoc capture / vktrace/GFXReconstruct trace), or an API dump, of a case where you see the wrong state is used? I'm hoping this might help us spot where things are going wrong here.
For reference, as there is a chance the Pixel driver there is modified in some way compared to a stock driver, one of the things we tested was the very basic case of a PSO with RD = true, and RD as the only dynamic state, and this set to false. We also tried some combinations of using a different PSO with a different static state earlier, as we've seen bugs related to this in the past, but it didn't seem to apply in this case. Have you seen even a basic case like this is not working correctly on this driver? (To be clear we've not tested on the Pixel specifically.)
In short, we tried a few 'possibly problematic' cases but struggled to get a repro so far, so hoping you might have some additional info which may give some hints. For sharing repros or similar please feel free to send us an email at developer at arm.com and we can take it from there. :)
Cheers,Christian
My apologies here, I hope I didn't cause you to waste too much time as after looking further into it, it seems to have been a bit of a edge case on our side.
Our backend was not properly handling the dynamic state 1 disabled (to workaround the stride bug) but dynamic state 2 enabled case thus causing the wrong number of dynamic states to be passed in at pipeline creation time leading to the issue. I'll try to be a bit more cautious reporting driver bugs next time :)
Thanks,
Billy
No worries at all! We really appreciate the reports; please do not hesitate to keep reaching out. :) We know how painful it can be to try to debug some of these things at API level -- with little-to-no insights into what happens inside the driver -- and so happy to try to help out wherever we can.