gpu: Support custom GPU counter groups

[dreveman]

Extend GpuCounterDescriptor with a new GpuCounterGroupSpec message
that allows GPU counter producers to define custom counter groups.
This complements the existing fixed GpuCounterGroup enum with
producer-specific grouping.

Changes:

• Add GpuCounterGroupSpec to gpu_counter_descriptor.proto (field 6),
  100% backwards compatible with existing protos.
• Extend gpu_counter_group table with name and description columns.
  Legacy enum-based rows have these as NULL.
• Parse counter_groups in gpu_event_parser for both legacy inline
  and interned descriptor paths.
• UI GPU plugin queries custom groups and creates sub-groups under
  Counters, e.g.:
  GPU > Counters > Compute Core > Counter A
• Document counter groups in docs/data-sources/gpu.md.

[github-actions]

🎨 Perfetto UI Builds

• 74c6c1e (2026-04-03 18:57 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-23957835322-1-ui/ui/index.html
• 5d34456 (2026-04-04 13:41 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-23979874567-1-ui/ui/index.html
• 8270c6c (2026-04-07 16:48 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-24093072235-1-ui/ui/index.html
• 713101c (2026-04-08 23:36 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-24163832700-1-ui/ui/index.html
• cc2601e (2026-04-09 13:17 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-24191887619-1-ui/ui/index.html

[LalitMaganti]

@dreveman really appreciate how much stuff has been improving here but I think we'll need to take a pause for a bit on reviews as this cl is non trivial and I need to think about implications here wrt to extending the concept of parent/child nested tracks outside of track event (as this is the first usecase of that).

I need to work on some internal facing things for a bit and won't be able to get to this for at least a week.

[dreveman]

@dreveman really appreciate how much stuff has been improving here but I think we'll need to take a pause for a bit on reviews as this cl is non trivial and I need to think about implications here wrt to extending the concept of parent/child nested tracks outside of track event (as this is the first usecase of that).

I was debating this myself. A single level of grouping might be enough if that helps? Which we already have today, just not implemented in the UI today, and useless for GPGPU workloads with the current predefined categories as everything basically falls in the COMPUTE category.

I need to work on some internal facing things for a bit and won't be able to get to this for at least a week.

No problem! I appreciate all the fast reviews and totally understand that you might have higher priority things to attend to.

FYI, almost everything I planned has been merged. This group improvement here and the correlation/flow stuff that I created another PR for but paused the work on are the only remaining things. Everything else needed for good GPGPU support is done as new UI plugins that can be upstreamed but can also continue to be maintained externally.

[dreveman]

@LalitMaganti No rush to review this. just FYI that I removed the support for nesting from latest version as it's not clear that's needed. One level of grouping goes a long way.

Alternatively, we could use the GpuCounterBlock proto that already exists instead of introducing the GpuCounterGroupSpec but given that the groups are already described to be a way to organize counters in the UI and the block system was not added to serve that purpose it seemed like the wrong approach to me.

[LalitMaganti]

That definitely makes it less controversial but still need to think about this when my plate is a bit clearer.