[LP] Visualize Model Artifacts with Model Explorer + ExecuTorch Extension#3413
[LP] Visualize Model Artifacts with Model Explorer + ExecuTorch Extension#3413matt-cossins wants to merge 10 commits into
Conversation
|
Had initial reviews by the model explorer team. Ready for further review. Note, this learning path requires small updates to the install process after this is finalised in the next week or so. It cannot be published until these changes are made. However it can be reviewed in the meantime. |
|
|
||
| ## Install the Arm adapters | ||
|
|
||
| {{% notice TODO before release %}} |
There was a problem hiding this comment.
Will you update this before merging?
There was a problem hiding this comment.
Before publishing, certainly - will update when the combined extension releases
|
|
||
| In ExecuTorch, ETRecord is the static side of the profiling workflow. It is produced at export time and preserves graph, operator, debug handle, and delegate partition metadata. This is the information that lets a runtime event map back to a graph node. | ||
|
|
||
| ETDump is the runtime side of the profiling workflow. It is produced while executing the model with ExecuTorch event tracing enabled. It can contain events such as `Method::execute`, `OPERATOR_CALL`, `DELEGATE_CALL`, backend-specific events, start times, durations, and cycle counts. |
There was a problem hiding this comment.
This might confuse readers. The ETDump provider explicitly filters out wrapper events such as Method::execute, OPERATOR_CALL, and DELEGATE_CALL, and currently exposes only aggregate node overlays.
Also, the first version of the ETDump data provider for Model Explorer only exposes timing information. We plan to add additional metrics in the future, so it may be better to describe the data more generically rather than listing specific event types.
| | `.etdp` | Runtime event trace | Timing data from a specific execution | | ||
| | `.pte` | ExecuTorch program | The packaged program and backend/delegate structure | | ||
|
|
||
| Without a matching ETRecord, an ETDump can still contain useful timing data. With the ETRecord loaded as graph context, the timing data becomes much easier to interpret because runtime measurements can be overlaid on the exported graph. |
There was a problem hiding this comment.
I think we should remove the first sentence: "Without a matching ETRecord, an ETDump can still contain useful timing data."
We need ETRecord to be loaded before user can use ETDump data provider so it might be better remove the first sentence to avoid confusion in this context.
|
|
||
| The [ExecuTorch ETRecord documentation](https://docs.pytorch.org/executorch/stable/etrecord.html) describes ETRecord as an ahead-of-time debug artifact. It contains the Edge dialect graph, debug handles, and delegate debug maps that allow runtime data to be linked back to graph nodes and, when available, Python source information. | ||
|
|
||
| For recent ExecuTorch versions, the recommended pattern is to enable ETRecord generation during export or lowering, then retrieve the ETRecord from the resulting program manager: |
There was a problem hiding this comment.
We recently added a Delegate visibility section (https://github.com/Arm-Debug/etrecord-adapter-model-explorer/blob/main/README.md#delegate-visibility) that explains how delegated ExecuTorch models are represented. It might be useful to reference or include this alongside the Generate ETRecord section.
|
|
||
| ## Load profiling overlays | ||
|
|
||
| The ExecuTorch extension for Model Explorer contains an ETRecord adapter and an ETDump data provider. The ETRecord adapter opens the exported graph. The first version of the ETDump data provider overlays runtime timing data on top of that graph. |
There was a problem hiding this comment.
The first version of the ETDump data provider overlays runtime timing data on top of that graph.
This could be confused that the timing data is rendered directly on the graph itself. It may be clearer to say that it is provided as information associated with the graph.
|
|
||
| If you pass only an ETDump to the Inspector, you still get runtime events. If you also pass the matching ETRecord, the Inspector can correlate events with graph operators and delegate metadata. | ||
|
|
||
| ## Load profiling overlays |
There was a problem hiding this comment.
Might be clearer to use "Load profiling data"
2 participants
Before submitting a pull request for a new Learning Path, please review Create a Learning Path
Please do not include any confidential information in your contribution. This includes confidential microarchitecture details and unannounced product information.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the Creative Commons Attribution 4.0 International License.