| 2 Jan 2024 |
 animats | And, about every 10 frames, the rendering thread stalls out for a bit in WGPU's "get_next_texture". | 07:19:58 |
 cwfitzgerald | Nothing looks terribly concerning in there | 13:03:28 |
| animats | OK. I suspect there may be lock overtaking problems, and the render thread is losing too much. I'll do some tests with more creation threads to force that. I've had trouble with crossbeam-channel mutexes in that area. If you acquire lock, do something, release lock, and soon re-acquire the lock, someone else waiting on the lock may not get in. It's over-optimized for the low-load case. | 19:01:56 |
| cwfitzgerald | this is in render-bench or your own code? | 19:04:19 |
| animats | In my own code. | 19:05:59 |
| animats | Render-bench doesn't have much locking. The update thread(s) just pound on Rend3. | 19:06:27 |
| animats | I want to see if more pounding locks out the render thread more. | 19:06:43 |
| animats | Incidentally, I don't think the framework ever delivers the "CloseRequested" event. I have a print statement there and it is not being executed. | 21:12:35 |
| cwfitzgerald | ah yeah, it just eats it and closes the window - that shouldn't be a return, it should still forward to the users | 21:20:16 |
| cwfitzgerald | * ah yeah, it just eats it and closes the window - that shouldn't be a return, it should still forward to the user | 21:20:17 |
| animats | I need to know about shutodown so I can stop all the other threads. | 21:20:48 |
| cwfitzgerald | you can catch the other event - it's probably more correct anyway Event::AboutToExit | 21:22:23 |
| animats | AboutToExit? Can't find that in winit or rend3 | 21:24:39 |
| cwfitzgerald | because that's not it's name 🤦 https://docs.rs/winit/latest/winit/event/enum.Event.html#variant.LoopExiting | 21:25:19 |
| animats | Ah. Much better. Now shutting down properly. | 21:28:43 |
| 3 Jan 2024 |
 marstaik | Im looking into doing some profiling, is tracy what you all use?> | 21:34:49 |
| marstaik | Never used it before | 21:34:52 |
 cwfitzgerald | yeah, that's the goto | 21:40:07 |
| 5 Jan 2024 |
| animats | Converted my big program, Sharpview, over to the arcanized version of Rend3. Graphics look fine. Content loading into the GPU is faster. Two panics so far, reported on Github as issues #552 and #662. We're getting closer! | 08:33:10 |
| animats | 
Download firstperf2.png | 21:49:58 |
| animats | Performance notes: So here's Sharpview, after loading a reasonably complex scene, which happens concurrently with viewing it. Content loading is still impacting frame rate. This shows the tail end of loading. Notice "Asset fetch queue", which indicates how much stuff is left to load. When that goes to 0 here, loading has stopped. Frame time is then around 27ms, for 38 FPS or so. That's the steady state. During loading, worst case frame times occasionally exceeded 200ms. I'm not sure why average frame times climbed so high towards the end of loading. | 21:49:58 |
| animats | In the steady state, the refresh thread seems to be at 100% of one CPU, and not much else is going on. GPU utilization is only 38%; the GPU has lots of headroom left. | 21:51:01 |
| animats | So, the takeaways are 1) content loading still impacts drawing too much, and 2) drawing is slower than we would like. Goal is a steady 60 FPS. | 21:52:39 |
| cwfitzgerald | Small note, this is still without arcanization, any improvements that have been made are rend3 stuff | 21:53:28 |
| cwfitzgerald | * Small note, this is still without arcanization, any improvements that have been made are rend3 side | 21:53:35 |
| cwfitzgerald | There are a few known bottlenecks in the rendering path right now which could be causing high frame tones | 21:54:30 |
| animats | Huh? This isn't with arcanization? I just upgraded Rend3. | 21:54:41 |
| cwfitzgerald | Nope, remember egui not updating to winit 0.29 (at the time) blocked a arcanization test branch | 21:55:24 |
| cwfitzgerald | wgpu 0.19 is coming out in two weeks with arcanization | 21:55:51 |
| animats | Oh, OK. That's actually good news. I thought we'd done all the improvements and it was still sluggish. Thanks. | 21:56:31 |
