Got a simple project that simply spawns 100,000 unlit cubes and moves them in a random direction at constant velocity from the center of the screen. When the cube leaves the screen, it is destroyed and a new one is added to the center of the screen with a random velocity.
@LeonhardP@Peter77 I just received an email about this from your one of your QA people, who said that it was because of vsync.
That’s not the case. I tried disabling vsync from settings, from code and even from drivers, and in any case the wait for target FPS spans multiple frames no matter the workload and vsync settings. This is what the profiler looks like when profiling a development build with vsync disabled:
You can just reply with your findings of what happens with vSync turned off, that will reopen the existing one.
However, what resolution are you running this on in the Editor vs the player? You could be GPU / fill rate bound. Try running both at the same resolution to compare them in a more representative way. Also, are both the editor and the player using the same Graphics API? Have you tried the GPU Profiler with this, or if that’s not feasible, a platform/GPU chip-specific profiler, e.g. vTune?
The CPU Usage Profiler only shows CPU timings. As explained in the Profiler documentation for such common samples, Gfx.Present can mean it’s waiting for VSync, or just for the GPU to finish drawing. As such, we can’t just conclude that the work would fit into 16ms because we’re not seeing all the stuff that is being worked on.
Also, we are painfully aware at the unfortunately sparse covering of GPU Profiling capabilities across Graphics APIs, platforms and configurations and the therefore lacking visibility and incomplete workflows in the Profiling offering and are working towards closing those gaps.
I feel pretty sure I’m not GPU or fillrate bound since I’m running this on a desktop computer with an 8GB AMD RX580.
When I get time I’ll deploy the project for PlayStation 4 and use the Razor GPU profiler to get a better picture of what’s going on.
Oh, and a reminder that the slowdown only happens when I’m running a BUILD. The performance is totally fine in the editor, regardless of viewport resolution. I can run it totally fine in fullscreen from the editor, where performance is usually significantly worse than in builds.
Thanks, that information was missing here and in the bug report so far. I was going by the screenshot at the top of this thread which shows a very small game view being profiled.
But yes, just to make certain, I’d set a fixed resolution in both editor and build, try windowed and fullscreen, and check again that the same Graphics API is used (set in the Player settings, if there’s multiple set and auto selection on the build could choose a different one than the editor.) Also the build might be using different QualitySettings?
If all that is isolated out and there’s still a significant difference, please respond to the bug with this additional info to reopen it.
