Revert "trace_processor: Parse adreno_cmdbatch_retired/submitted events (#5519)"#5793
Conversation
…ts (#5519)" This reverts commit ffaeb0c. Unfortunately this is necessary as this patch does *not* work on all QCOM devices: concretely, the events seem desynced from the render stage events which shouldn't really happen. Moreover, this also causes the raw ftrace event to be shifted which internal teams did not expect and were not happy with.
|
@rossning92 unfortunately due to some issues raised by internal clients (cc @batesj), we discovered that not all QCOM events seem to be emitting the correct timestamps in the If we want this patch, we should figure out how to detect whether these events are reliable or not based on the device/board etc and then make a decision on shifting the timestamps of these events |
🎨 Perfetto UI Builds
|
|
Thanks for letting me know @LalitMaganti @batesj! Do you happen to know which Qualcomm SoC has the desync issue or if there is a trace I can take a look.? I'll try to debug on my end. |
|
@batesj would be best to answer there, I'm not actually sure myself. |
|
@rossning92 Tested on a XR2+ Gen2 device and the new events were about two frames later than the corresponding Qcom renderstage GPU events. On a different device there was also an offset and additionally seemed to be some events at the start of the trace that were duplicated in the new GPU ftrace tracks. |
|
Thanks @batesj! I tested all the way from XR2Gen1 to XR2Gen3 devices, and both the render stage trace and the command batch trace align quite well (the difference is mostly on the order of dozens of microseconds). Since the kernel reporting is quite straightforward - it just emits the gpu active counter register and the kernel monotonic time at the same time for CPU <-> CPU sync via adreno_cmdbatch_submitted in events - so i had bit of hard time figuring out what might go wrong (e.g., could it be an incorrect timestamp or duplicated events). If possible, would you be willing to share your trace? that would make it much easier for me to debug this. |
|
@rossning92 Your renderstage events look different from ours so I'm not sure what other differences there are (for us the parent event is named just "Surface" instead of your "surface#0 ..."). Are your renderstage events coming from the Qcom Qprof integration that runs in each process with a GLES/Vulkan context, via this perfetto config? As a quick test, let's compare what you get in your traces with this query. Do the generated events line up with your GPU Cmdbatch events? |
@batesj ah I used Meta's integration based on I just redid the trace using the native renderstage event along with the SQL query you shared, and here are the results; they seem to align well:
If you could share the trace that would be extremely helpful - hopefully it's just a trivial bug! |
|
First let's look at some images showing the discrepancies that I'm seeing. If this doesn't help narrow down the problem for you let me know and I'll try to produce some sharable traces: Also note that we're talking about SoC versions but not driver versions which may also differ in how they produce both kgsl and renderstage data. |
|
@batesj this was super helpful! I think I may know what is going on. Originally, in my PR, I used only the first I opened a new PR for testing: #5817 wonder what might be the best way for us to testing this. If you have a couple of traces to share (even with only kgsl and renderstage events), I would be super happy to run through them on my end!
|
…ts (#5519)" (#5793) This reverts commit ffaeb0c. Unfortunately this is necessary as this patch does *not* work on all QCOM devices: concretely, the events seem desynced from the render stage events which shouldn't really happen. Moreover, this also causes the raw ftrace event to be shifted which internal teams did not expect and were not happy with.







This reverts commit ffaeb0c.
Unfortunately this is necessary as this patch does not work on all QCOM
devices: concretely, the events seem desynced from the render stage events
which shouldn't really happen. Moreover, this also causes the raw ftrace event
to be shifted which internal teams did not expect and were not happy with.