> The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue.

Yes. This is the big performance advantage of Vulkan over OpenGL. You can get the bulk copying of textures and meshes out of the render thread. So asset loading can be done concurrently with rendering.

None of this matters until you're rendering something really big. Then it dominates the problem.

I believe you can do loading texture data onto the GPU from another thread with OpenGL with pixel buffer objects: https://www.khronos.org/opengl/wiki/Pixel_Buffer_Object

I haven't tried it yet, but will try soon for my open-source metaverse Substrata: https://substrata.info/.

It is possible but managing asynchronous transfers in OpenGL is quite tricky.

You either need to use OpenGL sync objects very carefully or accept the risk of unintended GPU stalls.

Yeah you need to make sure the upload has completed before you try and use the texture, right?

Yes, and you need to make sure that the upload has completed before you reuse the pixel buffer too.

And the synchronization API isn't very awesome, it can only wait for all operations until a certain point have been completed. You can't easily track individual transfers.

Thank you. I hope to see progress in these areas when I visit later. I was hoping to be able to go all in on wgpu but if there are still legitimate reasons like this one to build a native app, then so be it.

It depends on your requirements and experience level. Using WebGPU is _much_ easier than Vulkan, so if you don't have a lot of prior experience with all of computer graphics theory / graphics APIs / engine design, I would definitely start with WebGPU. You can still get very far with it, and it's way easier.