What is limiting my fps in an empty project?

[aoidenpa]

To test, I'm only calling pixels.render() with a frame of 400x300 in my main loop and nothing else and my fps is around 60.0. When I run sandbox I get 120.0 fps. What is capping my fps? 60.0 fps can't be random right?
Edit: Using winit.

[parasyte]

Unless you've changed anything in the builder config, I would first suspect that you are using wgpu::PresentMode::AutoVsync as documented in PixelsBuilder::enable_vsync.

Your question kind of implies that your display is 120 Hz and that's what you expect out of Pixels... is that the case? ¹ I don't think I've heard of this happening in isolation. Usually software will want to synthetically limit the frame rate for various reasons. E.g.:

1. Examples consume a lot of CPU time when not visible on macOS #174
2. Fix delta time in the invaders example #252

Just some additional info, not necessarily related to your question. But I find it fascinating!
 

Footnotes

1. sandbox uses an older version of pixels with an older version of wgpu, and the internal implementation is possibly vastly different. ↩

[aoidenpa]

Thank you for the fast response.
My monitor is 60 Hz. I am on arch linux(btw :P) I was confused why fps was capped because I thought winit ran the event loop as fast as it can and it was up to me to limit it.
I did some experiments. You are right that sandbox is using older version of winit and an old fork of pixels. I don't see that sandbox is setting some configuration about vsync, so I assume difference is caused by different version of wgpu. You are also right this is about vsync.
For some reason I thought backend was vulkan but it wasn't. With Vulkan, my empty project(only pixels.render()) runs with 140 fps. Sandbox was using Vulkan. When I set it to use GL, it was capped at 60 fps as well.
I assume this isn't about vulkan being faster than GL. GL is limiting fps to the refresh rate of my monitor.
I also ran my project using GL and with "vblank_mode=0 cargo run" and got 2000+ fps. Same command with vulkan didn't have any effect.
Another thing, with both GL and vulkan, setting present_mode in pixelsbuilder didn't have any affect on fps.

I am very happy to learn more about this stuff but I must admit I am confused. Some questions:
1- If winit is responsible running the main loop, how can an external factor like wgpu affect the rate it runs?
2- What other environment variables affect the way rendering happens?
3- In practice, enabling vsync and limiting fps to monitors refresh rate is what I would want anyway right? It's only problem when it falls below that.
I am considering using pixels for some pixel art games and wanted to know more about performance. Like if I wanted to animate and move many objects, when would performance become an issue?

[parasyte]

1- If winit is responsible running the main loop, how can an external factor like wgpu affect the rate it runs?

winit does indeed control the event loop. But it doesn't control how quickly the callback must return. The callback¹ blocks in wgpu when calling SurfaceTexture::present(). It isn't very clearly documented, as far as I can see, but it's easy to prove with a minor patch:

diff --git a/src/lib.rs b/src/lib.rs
index 576b424..7826469 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -508,7 +508,9 @@ impl Pixels {
         (render_function)(&mut encoder, &view, &self.context)?;
 
         self.context.queue.submit(Some(encoder.finish()));
+        let start = std::time::Instant::now();
         frame.present();
+        dbg!(std::time::Instant::now().duration_since(start));
         Ok(())
     }
 

This shows that the call takes roughly 5ms on my desktop with a 180 Hz display (in the right ballpark):

[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.908ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.8614ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 5.0057ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.93ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.6233ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.5681ms
[src\lib.rs:513] std::time::Instant::now().duration_since(start) = 4.6969ms

2- What other environment variables affect the way rendering happens?

There are a bunch of variables that can affect rendering, directly or indirectly. Some are documented for pixels and wgpu. And on Linux, drivers are free to use environment variables for their own configuration. Mesa documents theirs.

3- In practice, enabling vsync and limiting fps to monitors refresh rate is what I would want anyway right? It's only problem when it falls below that.

Yes, but with an additional "catchall" frame limiter in place for cases where VSync either is not available or lies. That's what the linked macOS issue refers to. That issue has some other interesting links on the topic.

For the other end of the spectrum (app runs slower than the display) you need to start thinking about fixed timestep updates. And consequently, that's exactly what the other linked issue is about! The invaders example uses a crate called game_loop to provide fixed timestep updates that are independent of the rendering refresh rate.

I am considering using pixels for some pixel art games and wanted to know more about performance. Like if I wanted to animate and move many objects, when would performance become an issue?

Performance will become an issue when the frame buffer size is ... very large. CPUs are not ideal for writing pixels to a texture².

For small resolutions like most pixel games will be (I mean physical resolution as you see in pixel art. It can be scaled up to normal display resolutions by the GPU for free) the CPU won't be limited by drawing, but more likely by whatever other work your game needs to do; physics simulation, collision detection, pathfinding, ... There are many ways to eat into your per-frame CPU budget that are not going to be related to rendering at all.

Hope that's helpful!

Footnotes

1. And I have a bone to pick with this API taking a callback, and well, all async callbacks, really. But that's another rant! ↩

2. There are some tricks that can improve the situation. Split the texture into horizontal strips and make multiple threads fill them. Use filling algorithms that naturally transform nicely to SIMD instructions... But that's about as much parallelism as you will be able to squeeze out a CPU! GPUs are thousands of times more parallel, which is why they are good at drawing quickly. That said, I ran a test on my Ryzen 5900X and was able to push a raw 6,880x1440 frame buffer at about 1,000 FPS with these tricks. That was roughly the upper bound on what is possible with this CPU. But it means nothing else can be done on the whole system. And that refresh rate is absurdly high anyway. ↩