Dynamic sprite management - vulkan

Question

I'm learning Vulkan.
So far, in the sample programs that I've done, I've uploaded enough vertices to the GPU for drawing one or two quads. I also uploaded an image to display on the quad. It has all been very static.
I'm now interested in doing some dynamic tests -- specially, creating and modifying sprites on the fly. I'm not sure how to go about it, so I'm hoping to get some pointers about possible techniques. I'm trying to create a toy 2d engine, for learning purposes.
Basically, I'm not sure what's the best way to maintain the vertex data up-to-date on the GPU. Below is the definition for one quad:
struct Vertex2d {
glm::vec3 mPos;
glm::vec2 mCoord;
};
// Vertices for one quad.
const std::vector<fmk::Vertex2d> quadVertices = {
{{-0.5f, -0.5f, 0.0f}, {0.0f, 0.0f}}, // Vert 0: Top left
{{0.5f, -0.5f, 0.0f}, {1.0f, 0.0f}}, // Vert 1: Top Right
{{0.5f, 0.5f, 0.0f}, {1.0f, 1.0f}}, // Vert 2: Bottom Right
{{-0.5f, 0.5f, 0.0f}, {0.0f, 1.0f}}, // Vert 3: Bottom Left
};
const std::vector<uint16_t> quadIndexes = {
0, 1, 2, 2, 3, 0,
};
The vertex data represents the quad's position, rotation, scale, texture coordinates. Any of those properties could, potentially, change every frame. Also, new sprites can, potentially, be created or destroyed every frame.
Any pointers on data structures, techniques, functions, or any other info to managing sprites using Vulkan is appreciated.
EDIT:
I should add that I'm trying to avoid brute-force uploading all the vertices every frame. I'm currently trying to implement a brute-force approach, so that I can compare it with a good solution, once I've learned of one.

Answer 1

If You want to change positions of vertices stored in a buffer, You have two options:
You upload them from the CPU
You calculate them on the GPU
There are no other ways for the data to appear on the GPU. You either transfer it or generate.
The first solution is the one You call a brute-force, but in many situations You cannot avoid it. One way or another You have to transfer data to the GPU so it can use it for rendering purposes. Besides, transfer rates are quite high in today's GPUs. It is possible to transfer several dozen of gigabytes per second.
The second option is more procedural and doesn't require data transfer between CPU and GPU. To do that You either create a formula to calculate positions in a vertex shader on the fly, based on a time or any other parameter (without changing the original values). The second option, similar to transform feedback, is to calculate positions in a compute shader, store them in a buffer and then use that buffer for drawing purposes. Here is an example from a Vulkan Cookbook which does exactly that - draws particles (sprites) whose positions are calculated in a compute shader.
And don't forget that You don't need to transfer all the data with each vertex. To render a quad You just need a single position (center) and potentially a horizontal and vertical scale (size of the quad in each dimension). Offsets, rotations, translations and other operations don't need to be passes with each vertex, but only for the whole quad. So this also limits the size of the data You may need to transfer.