A budget is a decision tool

1131. Lesson identity

Module

3.7 — GPU and performance

Lesson

A budget is a decision tool

Academic type

Concept

Schema type

text

Order

1 in the module

Estimated time

30–40 minutes, including practice

1132. Learning objective

After this lesson, you can write one measurable performance budget that names a cost category, sets a threshold, identifies the test context, and defines the evidence required for a decision.

1133. Why this matters

A performance discussion is too vague when it only says that a scene should “feel smooth.” A budget turns that intention into constraints that can guide implementation and review. It also gives an AI coding partner a precise target instead of an invitation to optimize blindly. A measurement becomes useful when it can be compared with an explicit limit under a reproducible test condition.

1134. Prior knowledge

You should be able to identify the major responsibilities involved in producing a 3D frame and trace a visible result through scene state, camera, rendering, and presentation, as practiced in 3.6 L2 — Trace a 3D frame. You do not need prior profiler expertise. In this lesson, you only need to name an appropriate evidence source and sampling rule. The next lesson introduces how to collect and interpret those measurements.

1135. Core concept

A performance budget is a decision rule, not a wish list. It has five parts:

1. Cost category: what consumes time or memory.
2. Threshold: the maximum acceptable value or required range.
3. Test context: the hardware, resolution, scene, camera, and workload under which the threshold applies.
4. Evidence: the measurement source, sampling rule, and summary used to evaluate the threshold.
5. Response: the decision that follows if the result passes or fails.

Common measurable categories include:

A timing category must be defined operationally. For example, a budget may use the present-to-present interval reported by a platform presentation trace or the engine wall-clock frame duration reported by the engine frame-timing counter. Record which source and definition you use; similarly named counters from different tools may represent different boundaries.

Frame interval or engine frame duration is a throughput and pacing metric. It is not the same as the end-to-end completion latency of one logical frame, and it is not the same as input-to-present latency. Those latency measurements have different start and end points and require their own budgets and evidence sources.

Stability is not a separate cost category. It is a cross-cutting acceptance property: it describes whether a category remains within its threshold across repeated samples or relevant conditions. A stability claim must name the category being evaluated and specify a summary such as a percentile, maximum, or worst-case observation. For example, “GPU time remains at or below 12 ms across 120 samples” is a GPU-time budget with a stability requirement, not a sixth kind of cost.

The category must match the decision. If the problem is a long shadow pass, average loading time does not provide useful evidence. If the problem is a hitch during scene entry, a single steady-state frame is insufficient.

1136. Mental model

Use the C-T-C-E-R model:

Category → Threshold → Context → Evidence → Response

Write every budget line as a complete statement:

In [context], [category] must remain [threshold], measured by [evidence source and sampling rule]. If it fails, [response].

Example:

In the target gameplay scene at the selected display resolution, GPU time must remain at or below 12 ms in the worst tested camera position, measured with the GPU profiler over 120 consecutive frames. If it fails, inspect the highest-cost GPU passes before adding visual detail.

The response is part of the budget because a number without a consequence does not guide a decision. A threshold is also incomplete if the test context is missing: 12 ms in an empty scene and 12 ms during the busiest encounter are not equivalent claims.

1137. Concrete example

Suppose a small 3D gameplay scene targets 60 presented frames per second. The corresponding present-to-present interval is approximately 16.67 ms. For this budget, the team defines its frame metric as the interval between consecutive presentations reported by a platform presentation trace. This definition measures presentation throughput and pacing; it does not claim that one logical frame has exactly 16.67 ms of end-to-end latency, nor does it measure input-to-present latency.

The team might define this initial budget:

The 12 ms GPU limit and the 10 ms CPU limit must not be added to infer a 22 ms frame interval. CPU and GPU work can overlap, and synchronization or waiting can affect the observed presentation interval. The platform presentation trace, GPU profiler, and CPU profiler also report different boundaries. Their measurements are related evidence, not interchangeable numbers.

A present-to-present failure with CPU and GPU medians below their limits may indicate a worst-case sample, synchronization, frame pacing, presentation behavior, or another unmeasured part of the path. Conversely, a CPU or GPU threshold can fail even when the presentation-interval median is acceptable; that category still requires investigation because its guardrail has been exceeded. Record the same test context and aligned sample window so the evidence can be compared without treating the measurements as additive.

This budget does not prove that the scene is finished. It creates a decision surface. A separate end-to-end latency concern would need a distinct budget, such as an input-to-present threshold measured with a latency-specific method.

A weak version would say: “Keep the scene optimized and avoid expensive effects.” It names no category, threshold, context, measurement, or response. An AI system could generate many technically plausible changes from that instruction, but none would be anchored to a verifiable constraint.

1138. Common mistake

A common mistake is choosing a threshold from a general rule and treating it as evidence. Declaring “60 FPS” without naming the test scene, resolution, hardware, sample window, measurement source, or worst-case condition does not establish a usable budget.

Another mistake is using the phrase “frame time” without defining the counter. An engine frame-duration counter, a present-to-present trace, a GPU duration, and an input-to-present latency measurement do not necessarily share the same boundaries. Name the tool or counter and state what interval it reports.

Do not use averages alone when a brief hitch matters. State whether the decision uses a median, maximum, percentile, or another explicit summary, and keep the sampling context fixed when comparing results. Also do not classify stability as a cost alongside GPU time, CPU time, memory, or loading; stability describes how consistently one of those measured categories meets its threshold.

1139. Guided practice

Write one budget line for a performance risk in a 3D gameplay scene:

1. Choose one category: frame interval, GPU time, CPU time, memory, or loading time.
2. Describe the workload that must be protected. Include the scene or camera condition and, where relevant, resolution or hardware class.
3. Set a numerical threshold with units.
4. Name the evidence source and define what its measurement represents. Add a sampling rule or fixed checkpoint.
5. Write the response to a failure. Identify the next diagnostic or decision; do not jump directly to an unverified optimization.

Use this template:

Category:
Threshold:
Context:
Evidence source and metric definition:
Sampling rule or checkpoint:
Response if the threshold fails:

Then challenge your line with three questions:

• Could another developer reproduce the test without asking what you meant?
• Are the measurement boundaries clear enough to distinguish throughput from latency where relevant?
• Would the result cause a clear decision rather than merely produce another number?

Revise the line once if any answer is no.

1140. Validation / evidence

Your evidence is one completed budget line plus a short review note. The line passes when it:

• names one measurable cost category;
• uses a numerical threshold and unit;
• defines the workload and test context;
• identifies a measurement source and what its metric represents;
• specifies a sample window, summary, or fixed checkpoint; and
• states what decision follows from a pass or failure.

A reviewer should be able to mark each of the five C-T-C-E-R parts as present or missing. If the line concerns frame timing, the reviewer must also be able to tell whether it budgets an engine frame duration, a present-to-present interval, GPU or CPU work, or a separate latency metric. If you mention stability, identify the measured category and the rule used to judge consistency.

Do not claim that the budget has been met yet. This lesson establishes the constraint and evidence plan. The next lesson introduces collecting and interpreting measurements so an observed result can be compared with the threshold.

1141. Key takeaways

• A performance budget converts a quality goal into a measurable decision rule.
• Every budget line needs a category, threshold, context, evidence method, and response.
• Define timing metrics by their measurement source and boundaries.
• Frame interval or engine frame duration is not automatically the same as end-to-end or input-to-present latency.
• CPU and GPU timings must not simply be added because their work can overlap and their counters cover different boundaries.
• Stability describes whether a measured category remains within its threshold across samples; it is not a separate cost category.
• A budget is useful only when its result changes what the team does next.

1142. Next lesson

Continue to 3.7 L2 — Measure before changing / Medir antes de cambiar.

1143. Knowledge check