Is profiling of a native Unity plugin with RenderDoc, on Quest2?
If I wanted to profile a native Unity plugin responsible for rendering operations via OpenGL on Quest2, is this supported with the Meta fork of RenderDoc? I have included the following OpenGL push/pop debug groups throughout my plugin. GLES31Ext.glPushDebugGroupKHR(GLES31Ext.GL_DEBUG_SOURCE_APPLICATION_KHR, 0, -1, "myMessage"); When analyzing my capture with RenderDoc, I see my gl calls in the event browser, but I don't see the debug groups show up anywhere. I have ovrgpuprofiler enabled as well. Also, I don't see any values in the duration column of my event browser.485Views0likes0CommentsPlease help me understand Unity Profiler and RenderDoc output for my simple app
I have a simple scene that is performant on PCVR, but struggles to make a reasonable frame rate when run natively on Quest. After stripping out about half the scene geometry and some of the shadow overhead, it is still failing to run smoothly so I've run the Unity Profiler (Standalone) and RenderDoc to try to understand where my bottlenecks are. This development is currently running in Unity 2021.2.14f1, GLES, with up-to-date Oculus XR Plugin and Oculus Integration packages. Please look at the following and let me know if anything jumps out that I should look for. First, Unity profiler: The profiler suggests nearly 32ms of my 43ms PlayerLoop is waiting in EarlyUpdate.XRUpdate->OculusRuntime.WaitToBeginFrame. I've seen discussion online that suggests this is most likely related to "Vsync" like timing and missing a frame budget could cause excess time waiting on the next available frame. But I don't understand why it should appear to be almost 33 ms. At 13ms per frame @72Hzthat's almost 2.5 frame budgets every frame cycle. Because I can't get accurate timings of the GPU in the profiler, I can only see the Batches (20) and Tris count(~27K) and these should both be well-within recommended limits. I've highlighted what I *think* illustrates the RenderLoop timing as best I can and it seems to imply some 4-5 ms where the RenderThread is not in WaitForGfxCommands... Trying to dig deeper into the GPU, I've captured a frame under RenderDoc. Two quick up-front questions about RenderDoc and "Gather Timings", if anyone knows the answer... You must capture the frame under "Quest Mode", but can Replay it under "Quest Mode" or "Quest Profiling Mode" I get ~42ms under the former and 12ms under the latter. Which one is more trustworthy here? Should Gather Timings report times for each stage in the series, because I can only get it to report for the entire frame. I'd love deeper information for timing, but I can't seem to get at it. Finally, RenderDoc echoes the 20 Draw Calls, but I can't tell whether I'm doing anything else here which should be causing such poor performance. My overall framerate is around 27, but I can't understand why. Please advise if I've got something obvious going on, but I'm at a loss to explain the behavior I'm seeing. TIA, G76.6KViews2likes5CommentsInterpreting renderdoc meta fork tile timeline
Hi, I started profiling our application with the renderdoc meta fork, and i'm having trouble reading the results. The application is made with unity (2021.3 branch), and I'm profiling on oculus quest 2. Renderdoc is version 51.1, headset is up to date with firmware v51. Everything works fine on the capture / profiling steps with renderdoc; I can open a capture, click on "Time durations for render stages", and the tile timeline gets populated with the data I was looking for : Since I'm on quest 2, I'm expecting to see only one surface in the timeline, corresponding to the rendering in multiview of the application. So the rendering step works fine, but strangely there is an other surface being computed in the timeline right after. I cannot really relate this surface to anything in the application (there are no post effects set up in the project), but I can see with the tile browser that the surface seems to be affected by the fixed foveated rendering setting of the application, while the first one does not seem to be affected. Anybody would happen to know what this surface could relate to ? Thanks for the help,1.3KViews0likes0CommentsRenderDoc crashes apps
I am using RenderDoc Meta Fork 44.1 and Quest 2 with OS VERSION: 49068160412800150 and Version: 47.0.0.282.341.428237303 Lately, anytime RenderDoc launches a Unity built application, it crashes with a backtrace: /apex/com.android.runtime/lib64/bionic/libc.so /system/priv-app/VrDriver/VrDriver.apk ... After failing to launch, any subsequent attempts to launch within Quest or using Meta hub also fails with a crash until the headset is restarted. I should note the applications I tried start and work fine unless they are started from RenderDoc.955Views0likes0CommentsRenderDoc connected makes development build crashes instantly
Trying to use RenderDoc for the first time to debug frame from the device gpu. I made a unity build (Unity 2021.3.12 LTS) with development flag enabled and debug script enabled. Then I loaded it on the oculus, tested and it runs without issues. Then I switched from local to Device in the RenderDocMetaFork (v441), tried to launch the build from Launch Application tab like described here, but the build crashes instantly, if I try to open normally the build when RenderDocMetaFork is connected the build crashes.1.6KViews1like3CommentsRenderdoc for Quest: no Render Stage Trace
Following the instructions at https://developer.oculus.com/documentation/tools/tools-renderdoc-renderstage/ I expected to see a render stage trace. But clicking the "oculus logo" button in the Event Browser has no effect for me, and the Tile Timeline view is blank. I'm using Oculus Mobile SDK 1.402.3KViews2likes3CommentsQuest, RenderDoc, Vulkan, and UE 4.24.2
Hello, In the past, our team has been able to get RenderDoc captures from the quest for graphics debugging and analyzing performance, but having recently upgraded to the Oculus 4.24 Unreal branch with Vulkan enabled, we get a crash when trying to perform a capture, even with a grey-box test level. RenderDoc connects to the Quest and successfully launches the process, it only crashes on the capture itself. I've tried both the 1.6 stable and most recent (2020/4/26) nightly build of RenderDoc, with the same result. Is there an older version I should revert to? I also tried setting `adb shell setprop debug.oculus.zram 1` in case of memory issues, but it didn't help. Here is the crash callstack we get from the logs: Build fingerprint: 'oculus/vr_monterey/monterey:7.1.1/NGI77B/655140.4720.0:user/release-keys' Revision: '0' ABI: 'arm' pid: 17902, tid: 18209, name: RenderThread 5 >>> com.Sanzaru.NewGame <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdc r0 8cf04100 r1 00000000 r2 00000000 r3 00000000 r4 97d49f00 r5 8d569558 r6 0000003a r7 8d56a208 r8 b9231000 r9 e65c3620 sl fffffffc fp b9407cb0 ip e9047944 sp 8d5694c0 lr b99d6ff1 pc b9a2ab82 cpsr 680f0030 04-27 16:25:44.573 18303 18303 F DEBUG : backtrace: #00 pc 0008ab82 /system/vendor/lib/hw/vulkan.msm8998.so #01 pc 00036fed /system/vendor/lib/hw/vulkan.msm8998.so #02 pc 00012a5d /system/vendor/lib/hw/vulkan.msm8998.so (_ZN11qglinternal18vkBindBufferMemoryEP10VkDevice_Tyyy+28) #03 pc 00378ee5 /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #04 pc 002fe5f9 /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #05 pc 002fe289 /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #06 pc 0064456f /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #07 pc 00301b79 /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #08 pc 004c4bc3 /data/app/org.renderdoc.renderdoccmd.arm32-1/lib/arm/libVkLayer_GLES_RenderDoc.so #09 pc 00117a27 /system/priv-app/VrDriver/VrDriver.apk (offset 0xd83000) #10 pc 001178ed /system/priv-app/VrDriver/VrDriver.apk (offset 0xd83000) #11 pc 0010e8d3 /system/priv-app/VrDriver/VrDriver.apk (offset 0xd83000) #12 pc 000f753d /system/priv-app/VrDriver/VrDriver.apk (offset 0xd83000) #13 pc 000f87f1 /system/priv-app/VrDriver/VrDriver.apk (offset 0xd83000) #14 pc 00004c8f /system/priv-app/VrDriver/VrDriver.apk (offset 0xc0e000) #15 pc 0003dfb1 /data/app/com.Sanzaru.NewGame-1/lib/arm/libOVRPlugin.so (_ZN3OVR4Util22CompositorVRAPI_Vulkan11SubmitFrameEPK27ovrSubmitFrameDescription2_+48) #16 pc 000364e7 /data/app/com.Sanzaru.NewGame-1/lib/arm/libOVRPlugin.so (_ZN3OVR4Util15CompositorVRAPI8EndFrameEiRSt6vectorI20ovrpLayerSubmitUnionSaIS3_EEbPv+786) #17 pc 00023cd9 /data/app/com.Sanzaru.NewGame-1/lib/arm/libOVRPlugin.so (ovrp_EndFrame4+300) #18 pc 040383a4 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN9OculusHMD10FOculusHMD24FinishRHIFrame_RHIThreadEv+1212) #19 pc 0403da38 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN9OculusHMD14FCustomPresent25FinishRendering_RHIThreadEv+4272) #20 pc 0403c6d4 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN9OculusHMD14FCustomPresent7PresentERi+388) #21 pc 04a20ef4 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN15FVulkanViewport7PresentEP25FVulkanCommandListContextP16FVulkanCmdBufferP12FVulkanQueueS5_b+5256) #22 pc 049d7434 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN25FVulkanCommandListContext21RHIEndDrawingViewportEP12FRHIViewportbb+292) #23 pc 05ce5194 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN15FRHICommandList18EndDrawingViewportEP12FRHIViewportbb+112) #24 pc 06b05250 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN17FSlateRHIRenderer23DrawWindow_RenderThreadER24FRHICommandListImmediateR13FViewportInfoR23FSlateWindowElementListRK29FSlateDrawWindowCommandParams+20492) #25 pc 06b3541c /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so #26 pc 04a795b8 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN16FNamedTaskThread23ProcessTasksNamedThreadEib+3152) #27 pc 04a77f20 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN16FNamedTaskThread21ProcessTasksUntilQuitEi+108) #28 pc 05d562a0 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_Z19RenderingThreadMainP6FEvent+436) #29 pc 05db2f24 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN16FRenderingThread3RunEv+20) #30 pc 04b27780 /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN22FRunnableThreadPThread3RunEv+164) #31 pc 04a7316c /data/app/com.Sanzaru.NewGame-1/lib/arm/libUE4.so (_ZN22FRunnableThreadPThread11_ThreadProcEPv+80) #32 pc 00047d83 /system/lib/libc.so (_ZL15__pthread_startPv+22) #33 pc 0001a035 /system/lib/libc.so (__start_thread+6)2KViews0likes3Comments