[P2][RENDER] GPU profiling and render-pass inspector for AI agents

Open
  • Is something wrong?
#157 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
61/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend-api-design, observability

Research direction

Start at perf.get in src/control.rs, then read PerfReport and GPU pass reporting in src/render/mod.rs, src/render/gpu.rs, and src/render/gpu3d.rs; review the existing counters and capability decisions from #134, #150, and #151. Define the optional metrics and active settings metadata, then trace where prepare time, upload bytes, and memory estimates can be reported. Done for a focused slice means stable fields with clear units, unsupported metrics marked unavailable, and relevant tests or measurements included.

Written by the indexing model from the issue text.

Description

area: rendering help wanted priority: P2 type: feature

Problem and goal

Existing GPU timers and RenderStats are useful; expose a coherent machine-readable breakdown to agents and developers.

Implementation scope

  • Expose CPU extraction/prepare/encode, GPU pass timings, draw calls, triangle counts, culled instances, buffer-upload bytes and memory estimates.
  • Mark timestamp-unsupported metrics as unavailable, not zero.
  • Add MCP endpoint or structured control command to fetch recent frames and active quality settings.
  • Include a short example: agent requests report, changes quality level, then compares results.

Acceptance criteria

  • Structured schema with stable field names and clear units.
  • Minimal release overhead when disabled.
  • No fabricated GPU times for unsupported adapters.

Relevant code

  • src/render/mod.rs
  • src/render/gpu.rs
  • src/render/gpu3d.rs
  • crates/crabby_mcp/

Dependencies and notes

Builds on baseline instrumentation.

Compatibility: preserve existing public Rust and C/C++ APIs unless an independently approved design explicitly requires a breaking change. Collect correctness results and before/after measurements for performance-oriented changes.

Source audit and first contribution (2026-11-09)

Reviewed against source baseline df5c1d4 and merged implementation PRs through #167. The full issue acceptance criteria are still open; this audit does not mark the task complete. Existing priority is unchanged.

Starting point: perf.get in src/control.rs, PerfReport and GPU pass reporting already expose structured results. Extend these schemas rather than add a competing endpoint.

First slice: Specify optional/unavailable metrics and active settings metadata, then add missing upload/memory/prepare fields in stages.

Dependencies and coordination: Reuse #134/#150 counters and #151 capability decisions; unavailable GPU time is not zero.

Focused Rust-only PRs are welcome; a contributor need not complete this entire issue in one PR or also implement C/C++ bindings and guide chapters. Maintainers coordinate scoped documentation/native follow-ups. Preserve existing compatibility and supply tests/evidence relevant to the slice.

Dominant language
Rust
Stars
4
Forks
0
Avg merge
45m
Merged PRs (30d)
199

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ponkoengine/ponko

All issues in ponkoengine/ponko

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.