Seeking Guidance: GPU Particle Updates via wgpu Targeting WebGL (Compute Shader Alternative)

[lucascompython]

Hi there,
Firstly, I'd like to say that I'm new to wgpu and graphics programming in general, so I might have got some things wrong!

I'm working on a particle simulation project using and wgpu. I want to have simulation backends: CPU, Compute Shaders (for native/WebGPU), and a WebGL-compatible GPU method. I already implemented the CPU and Compute Shaders simulation backends.

In native OpenGL development, this problem is often solved efficiently using Transform Feedback. A vertex shader performs the physics calculations for each particle, and its outputs (new position, velocity, etc.) are directly captured into an output buffer before rasterization, using API calls like glTransformFeedbackVaryings, glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, ...), and glBegin/EndTransformFeedback.

Here is an example of C++ code using this technique, which achieves the desired GPU-driven update on WebGL (via Emscripten targeting WebGL directly):
https://github.com/Im-Rises/particle-simulator-webgl/blob/main/ParticleSimulator/Scene/Entity/ParticleSimulatorTF/ParticleSimulatorTF.cpp

Attempts with wgpu Targeting WebGL:

I've explored several approaches using wgpu to achieve a similar outcome (GPU-driven updates without Compute Shaders) when targeting WebGL, but encountered limitations:

1. Fragment Shader Storage Buffers: Using var<storage, read_write> in the fragment shader to write results back. This fails because neither Features::FRAGMENT_WRITABLE_STORAGE nor Features::VERTEX_WRITABLE_STORAGE are available on the WebGL backend.
2. Render-to-Texture: Writing particle attributes (position, velocity, color) to multiple render target textures in the fragment shader. This hits Limits::max_texture_dimension_2d issues when the particle count is high, as the texture width would need to match the particle count. It also requires complex texture-to-buffer copies.
3. Vertex-Only Pipeline + Buffer Copies: Using a render pipeline with only a vertex shader (and a dummy fragment stage to satisfy validation) where the vertex shader calculates the new state. However, wgpu doesn't seem to provide a mechanism to automatically capture these vertex shader outputs into a buffer like OpenGL TF does. Subsequent copy_buffer_to_buffer calls only copy the original data, as the destination buffer is never updated with the calculated results.

What is the recommended or idiomatic wgpu pattern that could help me achieve GPU-accelerated per-particle updates?

Is there an existing wgpu feature, technique, or combination thereof that allows capturing or writing back the results of vertex-shader-like computations to a buffer when the WebGL backend is used? Or is this specific type of GPU compute pattern currently infeasible through wgpu when targeting WebGL?

Thanks in advance!

[kpreid]

I cannot advise you on the best way to achieve functionality like transform feedback, but I do have a suggestion to improve one of your alternatives, Render-to-Texture: you can store more data by shaping your data into a 2D rectangle (wrapping to the next row at an arbitrary point ≤ max_texture_dimension_2d).

[lucascompython]

That's a great point, and I think it should allow processing of a large number of particles via the fragment shader.

My main hesitation with fully pursuing the render-to-texture approach right now stems from the performance implications compared to native OpenGL Transform Feedback.

As I understand it, the render-to-texture method, while performing the core physics calculations on the GPU, introduces overhead that native TF avoids.
RTT still requires running through vertex rasterization and fragment stages, while native TF can often discard rasterization.
And I still need that extra copy_texture_to_buffer strep to get the data back into the linear buffer for the next frame's input, right? This copy-back seems like it could be a significant performance hit compared to TF. Plus, it looks a bit tricky.

I'm still curious to know if this is the best/most performant way to do this in wgpu.

Nonetheless, this seems like a great idea.
I'll probably implement it, if I find nothing better.
Thanks for the suggestion!