The amazing green row is DOTS but notice that at low entity counts it underperformes vs Update(), Batch and Jobs until the number of moving cubes hit about 128.
The benchmark moves a set number of cubes for 1000 frames (uncapped) then records the results and adds more cubes 1, 3, 7, 15, 31 up to 16,383.
At least in this first attempt at a combined Benchmark what’s even stranger is there is some issue getting URP to render the cubes in the DOTS scene even with Hybrid Renderer 2 (HR2) works in editor not in build?
Not convinced this is the final benchmark due to this bug does the 0.8 ms frame time look right for a DOTS scene with a single moving cube and HR2?
That’s Quest 2. I have tested with DX11, DX12, and whatever I used for the Linux build (sorry, I forgot).
I’ve seen similar. There’s a fixed overhead for the scheduling that makes it not scale as well for a large system-to-entity ratio. This is an issue Unity is aware of and working towards improving.
Cheers for that changed to Vulcan restarted the edtior and my project now crashes on launch anyone know the file i need to change to reset the Graphics API so Unity will even startup?
You can open project and run commands from command line (terminal, powershell, cmd or whatever is your choice) by switching to the Unity editor directory with an executable and passing project path as an argument as well.
E.g. Unity.exe -projectPath “fullPath” -force-d3d12
This should prevent Unity Hub from openning, and would open project directly.
If your game is rendering at ~1200 FPS I don’t think you need a performance boost. In our experience, DOTS has massively improved performance in real game situations.
I would rather see the profiler flamegraph of each benchmark than the total frame time here. My guess is that the Hybrid Renderer is the bottleneck at low entity counts. We saw the same in our game and use a different approach. If you share the benchmark project we could make some suggestions and share our own results.
What if DOTS needs two sizes of system one for small sets of data one for large?
The idea being that the smaller lighter system can run in cache on chip providing super fast processing due to it’s tiny code memory footprint.
I’m guessing with DOTS Worlds, CommandBuffers and Code generation Entities opcode could be quit large and hence we need a lot of data to justify the overhead.
What if the small meta DOTS worked on the code generation side combining systems with small data loads reducing the overheads and maximising processing performance?
Or a super light version of DOTS where the systems code and data sets all fit on cache and can maximise performance for small data.
If you know the entity count is low it’s best to use Run instead of Schedule. Run will block the main thread so overall it could lead to worse performance even if the single execution time is better.
The actual overhead is from checking EntityQueries to see if the system should run (can be disabled with [AlwaysUpdateSystem] for custom systems), scheduling jobs, and combining JobHnaldes (there’s a scripting define called ENABLE_SIMPLE_DEPENDENCIES or something like that which can reduce the overhead of this for small main-thread-only projects).
Worked on the Batch / Jobs rendering using Graphics.DrawMeshInstance().
Still surprised the Jobs version in blue is slower than the Batch version. Tried different inner loop settings but I think it’s the overhead of using NativeArrays and passing the data to and from lists but that is only every 1000 frames when the next batch of cubes are added. I switched to a Persistent.Allocator which may also be slowing things down?
Unfortunately the amazing green bar for DOTS is cheating as the Hybrid Renderer is still refusing to render my entities apparently I need to pass new entities to the System via the mysterious Command Buffer (anyone know of good command buffer examples).
I was using the EntityManager to add entities and it was working then I upgraded and now can’t get things to render. This kind of unstable behaviour and ongoing changes are a big factor in why I keep having to stop trying to use DOTS.
That’s more like it switched how the Native Matrix4x4 array is split for the Graphics.DrawMeshInstance() and Jobs (blue) is now a bit faster than Batched (purple).
How come you aren’t using DrawMeshInstancedProcedural?
Do you have any custom IComponentData defined or are you just instantiating GameObjects with that script?
There is no active running beta right now. Only an alpha for 22.1. Recommended usage with DOTS is for 20.3 LTS, although some users have reported getting it to work in 21.2. I have no idea how many of them use HR V2 though. They might be using custom solutions.
The main thing I am trying to figure out is how you are spawning your entities. There’s a lot of components that are needed for HR V2, and depending on how you are spawning them, those components may not be getting added. If you select an Entity in the Entity Debugger and take a screenshot of all the components attached to it in the inspector, that may help us debug this.
Since it happens so rarely it’s probably not affecting anything, however, there’s this cool little trick you can do to avoid copying data back and forth between List and NativeArray where you get the inner pointer to a list, and then put that in a NativeArray. I’ve written about it here https://discussions.unity.com/t/831044/1
Also, what allocator you have shouldn’t really affect the speed of anything other than the actual allocation itself.
Would also be really interesting to see the code behind these experiments.
