Today marks one year since the Intel GPA project was discontinued.
At the time, I felt a real sense of emptiness. GPA was an external-facing tool, and working on something used by people outside my immediate team gave me a strong feeling of purpose. It was not only a technical project to me; it also became part of my professional identity and even helped support my extraordinary ability visa case.
Over the past year, working in architecture modeling has changed how I think about GPU performance analysis. I started to look less at application behavior as a black box, and more at the command streams submitted to the GPU, the hardware blocks they touch, and the metrics that describe how those blocks behave. That perspective made me rethink what future GPU tuning workflows could look like.
If we have a reasonably structured architecture map and a useful set of GPU metrics, performance analysis can become more than reading counters after the fact. Metrics can be attached to specific parts of the GPU pipeline: command submission, render and compute engines, fixed-function blocks, execution units, cache, memory fabric, and local memory. A number such as stall, occupancy, bandwidth, cache hit rate, or latency becomes more meaningful when it is connected to where it happens and which workload path produced it.
This naturally suggests a closed-loop workflow:
engine-native scenario → metrics sampling → architecture-aware bottleneck hypothesis → targeted experiment → resampling → explanation
Instead of only asking an external tool to reconstruct what happened in a captured frame, we could ask the engine to provide deterministic and parameterized workload scenarios. An agent could then sample metrics, reason over the architecture map, form a bottleneck hypothesis, adjust parameters or command-list behavior, and run the scenario again.
This is where AI agents become interesting to me. A human engineer is still needed to define the right questions and judge the results, but the repetitive loop of sampling, comparison, hypothesis refinement, and report generation is exactly the kind of workflow an agent can assist with.
In that model, GPU performance tuning becomes less about manually browsing a reconstructed frame, and more about running controlled experiments with architecture knowledge in the loop. That is the idea behind the visualization I made: not a finished tool, but a small reflection on where graphics performance analysis may be heading.
I have finished a local C++ library to connect MDAPI with my idea. Maybe one direction to finish this project is to have a MCP server that provides basic knowledge and tool to guide agents “how to tune Intel GPUs”.
Leave a Reply