Your Full NameTechnical artist
← Back to work

Performance / Optimization study

GPU Budget Investigation

A profiling study that compares visual quality, frame cost, and memory pressure across material variants.

RenderDocUnity ProfilerGPU timingsMemory budgets
No preview mediaThis study is intentionally documented without a hero image.
Selected workCase study media
Role
Technical Artist / Profiling
Contribution
Built the capture matrix, isolated the expensive passes, and documented the quality trade-offs for art review.
Engine / environment
Unity URP / RenderDoc
Platform
Integrated GPU / Desktop GPU
Status
Investigation
Team context
A deliberately small corpus used to validate performance reporting in the portfolio framework.
Year
2026
Technologies

RenderDoc · Unity Profiler · GPU timings · Memory budgets

Investigation protocol

Baseline -> capture -> hypothesis -> experiment -> result. The page uses explicit measurements instead of a vague claim that the material is "optimized."

Observed measurements

GPU time4.8 -> 3.9 msBaseline to selected variant
Texture samples18 -> 14Common material path
Transient memory42 -> 39 MBRepresentative frame
DecisionVariant AKeeps the readable cue
Rounded measurements from the same 1920x1080 capture matrix.
  • Baseline: 4.8 ms GPU, 18 texture samples, 42 MB transient memory.
  • Variant A: 3.9 ms GPU, 14 texture samples, 39 MB transient memory.
  • Variant B: 3.4 ms GPU, 11 texture samples, 36 MB transient memory, with a visible loss in grazing-angle breakup.
  • Decision: ship Variant A for the common path and reserve Variant B for the low tier.
profiling-summary.txt
Capture: 1920x1080 / 60 Hz
Pass                 Baseline   Variant A
Material evaluation   2.1 ms     1.5 ms
Shadow resolve        0.9 ms     0.9 ms
Post processing       1.8 ms     1.5 ms

Decision

The fastest result is not automatically the best production result. The acceptable option preserved the visual cue artists cared about while reducing the cost enough to protect the frame budget.

Case study

Problem

The original review format made it easy to show a capture but hard to compare measurements and explain what was intentionally sacrificed.

Case study

Constraints

  • Do not trade away the only readable material cue.
  • Keep the result understandable without opening a profiler.
  • Make the capture conditions explicit.
  • Separate measured values from interpretation.

Case study

Technical breakdown

The study treats GPU time, texture samples, and transient memory as separate signals. A single "performance score" would hide the reason for the decision.

Case study

Results / impact

The test demonstrates that the framework can display quantitative evidence as text and code, but it also asks whether metric data deserves a dedicated, more scannable component.

Case study

Trade-offs

The portfolio version reports rounded values and omits project identifiers. A production review would keep the capture file and exact hardware profile alongside the summary.