How to display GPU profiling data?
In addition to enhancing our test utilities both to perform more (and more interesting) tests, we are also enhancing them to generate more data on where the system and the GPU are spending their time. This will likely leave us in a situation where we are faced with the challenge of making sense out of all of this information and drawing conclusions about how to apply the results (new optimizations, new tests, etc.). We need a good way to distill the data we will be collecting into a coherent format for analysis.
Blueprint information
- Status:
- Complete
- Approver:
- Jesse Barker
- Priority:
- Medium
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Alexandros Frantzis
- Definition:
- Approved
- Series goal:
- Proposed for trunk
- Implementation:
-
Informational
- Milestone target:
- None
- Started by
- Alexandros Frantzis
- Completed by
- Alexandros Frantzis
Whiteboard
Summit session notes:
* What data do we care about?
* Application specific (custom information that each app emits)
* Application independent (gl calls, textures memory, swaps/sec, cpu usage)
* Some data can only be supplied by the driver
* Special driver interface? EGL extensions?
* Non-gfx related data (eg cpu usage)
* We can:
* Change the tracing tools to capture other data
* Sample in parallel while capturing the trace
* Sample in parallel while replaying the trace
* Formats
* Tracy
* Apitrace
* BuGLe
* New format?
* Format Converter tools?
* Do we want to integrate with a specific tool or have our own GUI?
* How to display
* graphs with frame # on X-axis
* Statistics
Proposal: tracing at application independent layers (OpenGL ES, EGL, etc.).
Discussions around profiling tools and questions around what kinds of data are being collected...
What do do around non-graphics related data? Is trace replay a viable way to profile?
The concerns are that trace replay is not representative of real application behavior. We need to be careful in the conclusions we draw based upon these methods.
Discussion: Trace formats. Do we use one of the utility specific formats (see whiteboard on blueprint for list)?
Work items (tentative)
[ACTION]: Evaluate extant profiling tools (perf, ftrace, oprofile, etc.) to see how they are presenting data.
[ACTION]: Evaluate "kernel shark" to see GUI frontend (GTK based).
[ACTION]: Contact GPU vendors about perf counters. Could we add GPU functionality to perf/oprofile?
[ACTION]: Evaluate "common trace format".
[ACTION]: Determine if BuGLe supports GLES 2.0.
[ACTION]: Fix on a particular trace format.
[ACTION]: Fix on a special-purpose user interface for the duration of this cycle (prototype to be spec'd).
[ACTION]: Determine interesting statistics.
[ACTION]: Define use cases for user experience.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
