Yes, so what’s happening is that in order to issue draw calls you need to create and bind these “render pipelines”, which basically contains a description of all the render state of the graphics pipeline. E.g what shaders you are using, what the vertex layout looks like, if you are using alpha blending etc. Typically in a pure vulkan based application, these pipeline objects are known and created before you render anything so you avoid costly state changes like in OpenGL where dynamic state changes can happen at any point in time. If the jerks happen mostly on iOS/OSX device it’s likely it has something to do with the vulkan -> metal wrapper (MoltenVK), and I’d have to run some profiling in order to spot that.
But solution wise, what you could do right now before we can look at the issue, is to “pre-warm” your pipelines by issuing draw calls with the materials and render state you want to use. You don’t have to render anything for real, just that the renderer has to “see” the pipeline once so it can create it and keep it for the rest of the app lifetime. There is one thing that also could help that I’ve yet to look at, which is to add support for “pipeline caching”, which is vulkan API functionality that saves your prebuilt pipelines to persistent data storage and reuses those instead of building them. It should be an “easy” fix but I can’t promise when this would be available, plus it would only help successive runs of the app but probably not the first time.
edit: @roccosaienz ^