[Resolved] WGPU application running at 1 FPS with 60 * 144 Render passes per second

[RaoulLuque]

Edit: I capped the framerate at 1 FPS (see my comment) and actually WGPU can handle the workload described in the following:

I am currently working on a GameBoy emulator written in Rust using WGPU for the rendering. I hoped that with this approach it would support both Desktop and Web. However, I had several problems with getting it to be compatible with the Web.

My rendering setup is as follows:
The GameBoy has a Framerate of about 60FPS, so I just target this. Every frame, the gameboy actually renders 144 scanlines (horizontal lines of 1 pixel height) to the screen. This is kind of key, because some effects/games use this rendering since between scanlines some scrolling values can be changed, so I would like to emulate this.

Therefore, I tried the following:
Render a Frame every 60 fps using a render_pass to the screen. Then, call a compute shader 144 times a frame, each of which render the scanline (when it is ready). This worked relatively well - on desktop. Some of you might already be thinking that this does not work in the web, with WebGL2 at least. This is what can be seen in the main branch of my Repo:
https://github.com/RaoulLuque/RustBoy

Hence, I ended up trying the approach of using an "offscreen texture" to buffer/store the frame in and render one line to this buffer144 times per frame. This is what can be currently seen in my "offscreen_framebuffer" branch:
https://github.com/RaoulLuque/RustBoy/tree/offscreen_framebuffer
However, with this approach I have creeping framerates of around 1, whereas before I had 60 FPS (I capped my FPS so possibly I would've had more).

Am I doing something wrong or is there another solution which works both on Desktop and with WebGL that can handle this? It seems like a problem that should be adressable.

[grovesNL]

144 render passes is probably too many. Most games and applications try to use as few of these as absolutely necessary (e.g., because you need to read the results of a previous pass) and instead batch writes together.

I'd recommend trying to start with a one or two render passes and finding ways to make it work within that constraint if possible. So maybe you could try something like this instead:

• start a render pass
• draw each line within that same render pass,
• end the render pass

[RaoulLuque]

However, I would still be interested in what you just suggested. Would start a render pass and then draw each line within that same render pass mean that the buffers I use have the same value across all lines being rendered?

[grovesNL]

Each scanline wouldn't be able to see what the previous scanline wrote (e.g., if you draw in order, the scanline at row 1 wouldn't be able to see what the scanline at row 0 just wrote during the same render pass), but the inputs for the draw calls can be different.

You could use different vertex buffers (or different parts of the same vertex buffer) by using pass.set_vertex_buffer, different index buffers, different pipelines, etc. within the same render pass. So within the render pass, each scanline could say "use this specific slice of the index buffer and vertex buffer, then draw".

[RaoulLuque]

I see, well sorry for bothering you here, I will try to look into that. I often times find it hard to find the resources I am searching for mostly because I just lack the words to describe what they are since I don't come from GPU programming or anything. So is there a word describing what you are saying?

Also: Just to make sure I understand it correctly, you are desribing using different vertex and index buffers, however I was thinking about the tile data buffers I use and other information specific to gameboy emulation which I set after dropping the render pass, right? So all of these lines being rendered would use the same values for these buffers right? Because I drop the render pass before even updating the buffers, at least with the approach I learned in the Learn WGPU tutorial.

This is interesting because these buffers change between scanlines, so I would have to have a way of updating them between scanlines. That's why I thought I'd need a new render pass for each scanline.

[grovesNL]

Right, you could use different tile data buffers within the render pass too. The idea is to prepare all tile data buffers before starting the render pass, then each scanline can use them without starting new render passes each time.

I'm not sure if learn-wgpu talks much about this approach but the wiki page for encapsulating graphics work talks about this idea a little bit https://github.com/gfx-rs/wgpu/wiki/Encapsulating-Graphics-Work

[RaoulLuque]

Ah, I see now. That makes sense. Thanks so much for explaining :)

[RaoulLuque]

Edit: I just noticed that I left my FPS capped at 1 FPS which I did for some testing. Setting the cap to the intended 60 FPS everything works fine and I have no performance issues. On the contrary, WGPU even seems to be capable to handle around 120-130 FPS for this workload (there is still the option of course of there being other artificial bottlenecks in my code).

Therefore, I would instead frame this discussion as saying: Using a render pass 60 * 144 times per second is possible. So thanks for making that possible WGPU :)