Working on this bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6012
Current code: https://gitlab.com/cheako/vk-layer-cache/-/blob/BROKE001
The methodology should be self-evident. The application makes calls into Vulkan and this drastically affects the frame rate. The idea is to eliminate as many of the calls as possible, to reduce the places needing auditing. This is done by remembering what VkObjects were obtained via a CreateInfo and returning those in the future for the same CreateInfo, without calling Destroy or Create. Not worrying about being correct, as this only needs to work the one time in testing and under close supervision.
1. There is an issue I don't think is solvable. I'm trying to prevent a call to VkCreateGraphicsPipeline, by re-using a destroyed pipeline. Actually for pipelines NMS(the application) creates the same one several times! So I've done the awful thing of returning the same VkPipeline for multiple VkCreateGraphicsPipeline calls. What get's me is the call to VkCreateRenderPass, see it's used in the VkCreateGraphicsPipeline and it's impossible to guess what VkPipelineCreateInfo the VkRenderPass will be used in... So calling VkCreateGraphicsPipeline is unavoidable.
2. This creates some strange behavior, I think it needs at least another set of eyes. Particularly problematic is the "p" command, it seems to cause the application to exit without much fan fair or the printing of errors. Doing
for ech in Q W E R T Y U I O P A S D F H J K L Z X C B N M t; do echo $ech | nc -U /tmp/cheako_cache_sock; done
should wipe everything, but it causes the entire desktop to go belly up. I'm sure that come as no surprise, but I'd like to learn(even to know) why.
3. I'd like this to work on Windows. I don't know anything about that platform, other than the secret magic of "format C:\" and it's healing powers. I'm interested to know how IPC would work without sockets, or would I really just listen on 127.0.0.1:xxxx?
4. I think this tool would find applications in other areas of debugging Vulkan.
