#It would be really weird if the editor
teal nebula
Ah, no it wouldn't; that is how Unity works. Check your profiler when running in the Editor.
Also, that gap would be where frame rate matching would occur when running in a build.
wanton fjord
Hmm... Indeed, the editor loop seems to be in the middle. However, that still doesn't explain what you're trying to do. Are you trying to execute something where the FrameEvents.XRBeginFrame is run?
teal nebula
I am trying insert my own subsystem after FrameEvents.OnBeforeRender but the PlayerLoop class does not return any subsystems after frame rate matching would occur (i.e. none of the before render, render, or post render subsystems).
wanton fjord
Why do you need that. What are you trying to do?
teal nebula
Sorry, I thought I already explained this. I am trying to close the latency gap between simulation update and render update with my custom subsystems as is necessary for XR rendering.
wanton fjord
What gap are you talking about?
teal nebula
wanton fjord
These ~8ms after PresentationSystemGroup and before OnBeforeRendering?
looking at the timeline, the batches are created in the Presentation group. Whatever it is you want to do, it's not gonna be rendered on this frame anyway. And you can't do anything about frame sync.
But you can run your logic on a background thread if the intention is to keep it running while the main thread is waiting.
Actually, I feel like the work is submitted to the GPU over there as well.
So it probably just waits for it to finish working.
teal nebula
Sorry, @wanton fjord. Thank you for your help, but I think you might want to refamiliarize yourself with Unity's frame processing and how updates and rendering work as what you are attempting to describe is incorrect. Batches for rendering and submission occur after frame rate matching during the render subsystem processing (which builds the commands that are executed on the render thread). Your statement that, "Whatever it is you want to do, it's not gonna be rendered on this frame anyways..." is entirely incorrect. Your continued assertion that, "... And you can't do anything about frame sync" is also entirely incorrect. This is how rendering for XR works now; look into the TrackedPoseDriver implementation for details. Also, peforming render specific updates just before render is quite common (check out Application.onBeforeRender, Camera.onPreCull, Camera.onPreRender, etc.).
wanton fjord
Camera.onPreCull, Camera.onPreRender - these are all performed while the commands list are/is constructed before it is submitted to the GPU.
I'm not entirely familiar with ECS rendering or XR.
But looking at the URP renderer details, the frame rendering itself is submitted long before the frame is complete. The final blit is what's creating the final render target and should be submitting it to the screen. After that there's only cleaning up.
Granted, we can only speculate what actually happens at the lower level where unity invokes the graphics API, since we don't have access to the source code.
Also, the positions of the calls in the timeline are probably not very representative of the real timing
teal nebula
Sounds like you are still a bit confused on how a frame works. Here is a screenshot of the main thread of a single frame in the profile running against the editor. The portion of the frame with the green arrow is where all frame simulation logic occurs (Initialization, Fixed Update, Update, LateUpdate). The portion of the frame with the red arrow is where frame rate matching (and some others) occur both in editor and in a build. The portion of the frame with the blue arrow is where rendering occurs (before render, render, post render). The simulation portion of the frame updates all data and can create graphics command for submitting. The frame rate matching portion ensures we are waiting on the render thread to be ready to accept commands for rendering this frame. The rendering portion of the frame performs the setup for rendering, the creation of render commands, and the submission of commands to the render thread for actual rendering to the screen buffer and final submission. Also, the positions of the calls in the timeline are absolutely representative of the real timing; that is what the profiler is for.
