Hi,
I’m assuming I’m doing something very wrong as I’m currently only getting around 6 FPS and I was hoping to have way more object rendered in the scene than this. The view below consists of maybe only a dozen or so unique meshes and all objects in the scene share the same material using a Texture2DArray with UV offsets, so assume I would get good performance with DOTS instancing. The tri/vert count is very high due to a tree asset I need to replace (unless that’s the issue?). I’ve tested in a build and get identical poor performance.
I’ve attached some profiler snapshots. It shows the bottleneck on StartUpdate within UpdateAllBatches. Does Semaphore.WaitForSignal mean its waiting on something else to complete first? I.e. the problem is elsewhere?
if you want to rule out the tree being a problem you could try switching the mesh temporarily with something like the builtin cube mesh, and see what the performance is like after
Thanks @runner78 . You mean release mode under the build configuration settings? Have changed that to release now. Still get poor performance in build as well.
The other three items are ok.
Would it be possible to get a screenshot of the profiler with more of the render thread and job threads visible? Potentially also a bit more what happens before hybrid starts updating StartUpdate is waiting for some job chain that seems to be running for a long time.
Also, what version of hybrid/dots is this?
EDIT: You might actually be fully GPU bound and the uploader in hybrid is waiting for a new set of buffers to become available.
If I get rid of the trees and replace all buildings with simple cubes I’m down to 20M tris @ FPS. Ok so maybe I need to check the assets and add LOD/Culling to reduce it further.
The profiler initially shows several physics jobs (I have a static trigger box collider on each building) followed by LOD jobs, before the long idle period.
I’m on Hybrid Renderer 0.10.0, Entities 0.16.0, Unity 2020.2.0b9.
It does look like you are GPU bound. Hybrid 0.10 has a new frame queuing limit to avoid overwriting live GPU data and that might wait for the GPU to be done with drawing of some previous frames. This is a stopgap measure we will improve on and you can disable it by adding the script define DISABLE_HYBRID_RENDERER_V2_FRAME_LIMIT
It might or might not improve your situation. If it does improve your framerate something is broken on our side and will need fixing.
If it does not improve frame rate for you you are probably GPU bound.
Adding the script define didn’t improve things. Thanks @joelv ! I wasn’t paying attention to the GPU as the editor stats were showing the CPU working hard. Definitely some problematic meshes in there I can tidy up and sort it.
I guess this has been answered by “It’s GPU bound” but just to reiterate: Yes. Semaphore.WaitForSognal is a threading sample, i.e. it always implies that the thread it occurs on is waiting on work on a different thread. Looking at where it ended and what else ended around that time mark on a different thread is the way to go, unless there is a flow event registered with the samples. (New in 2020.1, their visualization can be turned on on the Timeline view toolbar via the right most three dot button)
I realized the profiling scopes here is not very good, thank you for highlighting that. We have decided to do some minor changes so that time waiting for GPU will not be shown inside hybrid renderer any longer. This will make it more clear to you when you are CPU bound and when you are GPU bound.
