[dc443]

> WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports.

This is really helpful for me to learn about, this is a key thing I want to be able to get right for having a good experience. I really hope WGPU can find a way to add something for this as an extension.

[dc443]

Do you know if these things I found offer any hope for being able to continue rendering a scene smoothly while we handle GPU memory management operations on worker threads?

https://gfx-rs.github.io/2023/11/24/arcanization.html

https://github.com/gfx-rs/wgpu/issues/5322

[jms55]

The actual issue is not CPU-side. The issue is GPU-side.

The CPU feeds commands (CommandBuffers) telling the GPU what to do over a Queue.

WebGPU/wgpu/dawn only have a single general purpose queue. Meaning any data upload commands (copyBufferToBuffer) you send on the queue block rendering commands from starting.

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

WebGPU/wgpu/dawn would need to add support for additional queues: https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aiss...

There's also ReBAR/SMA, and unified memory (UMA) platforms to consider, but that gets even more complex.

[Animats]

> 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.

[Ono-Sendai]

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/.

[exDM69]

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.

[Ono-Sendai]

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

[dc443]

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.

[jms55]

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.

[Animats]

Short version: hope, yes. Obtain now, no.

Long version: https://github.com/gfx-rs/wgpu/discussions/5525

There's a lock stall around resource allocation. The asset-loading threads can stall out the rendering thread. I can see this in Tracy profiilng, but don't fully understand the underlying problem. Looks like one of three locks in WGPU, and I'm going to have to build WGPU with more profiling scopes to narrow the problem.

Very few people have gotten far enough with 3D graphics in Rust to need this. Most Rust 3D graphics projects are like the OP's here - load up a mostly static scene and do a little with it. If you load all the content before displaying, and don't do much dynamic modification beyond moving items around, most of the hard problems can be bypassed. You can move stuff just by changing its transform - that's cheap. So you can do a pretty good small-world game without hitting these problems. Scale up to a big world that won't all fit in the GPU at once, and things get complicated.

I'm glad to hear from someone else who's trying to push on this. Write me at "[e-mail]", please.

For a sense of what I'm doing: https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

[Ono-Sendai]

What I do currently is just limit the amount of data uploaded per frame. Not ideal but works.

[Animats]

That works better in game dev where you have control over the content. Metaverse dev is like writing a web browser - some people are going to create excessively bulky assets, and you have to do something reasonable with them.

[Ono-Sendai]

It works with large assets too. Just split the upload into chunks.

[0x1ceb00da]

Do you have any references? I thought all wgpu objects are wrapped with an Arc<Mutex<>>.

[jcelerier]

That sounds wild to me. In c++ I remember a time where I increased the frame rate of a particle renderer from 20fps to 60fps+ simply by going from passing shared_ptr (Arc equivalent) to passing references.

[0x1ceb00da]

Nevermind. Just an Arc<>.