Two kinds of completion — Parallax Sketchbook

SKETCHBOOK / 06 The Living Gallery · 2-week chapter

Page 1 of 3: Submission is not completion

CPU / GPU timeline

Submission is not completion

A CPU function returning from command submission does not mean the device has finished using every referenced buffer, image, or descriptor. Draw the CPU and device timelines separately, with a resource-use interval that extends beyond the submitting call.

A CPU worker join proves the joined CPU work has finished. It says nothing by itself about commands already submitted to a GPU. Similarly, a shared_ptr reaching its final CPU owner does not establish device completion unless that owner is connected to a backend retirement policy.

The supplied engineering companion is CPU only and creates no GPU objects or fences. This chapter is a design model for your later graphics API work. Use actual backend documentation and validation tools when implementing it; a simulated completed counter is not a fence.

TRY IT IN YOUR STUDIO

Draw an upload owner, a submitted draw, a later completion event, and the earliest safe destruction point. Mark which events the CPU companion can and cannot observe.

From the page to your own work

Your studio assignment.

Design the Living Gallery’s resource lifetime across CPU preparation and eventual GPU presentation.

A finish line you can see

A two-timeline diagram, a bounded retirement policy, and a clearly labeled pure state-model test.

Do not use a counter as pretend device completion.
Separate logical asset revision from physical resource release.
Define queue pressure and shutdown behavior.
List the backend documentation and validation still required.

Keep the evidence in your weekly notebook ↗

Explain it like an engineer

Try answering aloud before opening the review notes. Use your own implementation as evidence.

Why can a live resource still be used incorrectly by the GPU?

Liveness does not establish execution order or memory visibility.
Different stages and queues need the backend’s synchronization rules.
Completion scope must cover the actual submitted use.

These prompts support practice; they are not an automatic assessment of your work.

A tip for this exercise

Draw CPU preparation and device use on separate timelines, with logical asset replacement marked independently. Keep this exercise labeled as a state model until a real backend supplies observable completion and synchronization evidence.

Hints, when you need them.

Try a first step, then reveal as much help as you need. Each hint gets a little more specific.

1Hint 1 · Find a starting point

Find the last submitted use of the old resource, rather than the moment a new generation becomes current. Identify which completion requirement actually covers that use.

2Hint 2 · Choose an approach

Model retained owners with explicit pending-use requirements and a maximum retirement-queue size. Choose a response when the queue is full, and write down the backend-specific shutdown questions still unresolved.

3Hint 3 · Check your reasoning

Give an old generation two modeled in-flight uses. Completing only the first must retain its owner; releasing it becomes eligible after all required uses finish. Simulated completion values provide no evidence of real device ordering.

A small creative variation ↗

Model an old generation used by two in-flight frames and identify the last required completion.

Optional. Save it for later if this chapter already feels full.

Coming back after a break? ↩

Draw one buffer and one submit/completion pair without writing any backend code.

Books & principles behind this study +

Original Parallax explanations and assignments, with these works for further reading.

YOUR MARGIN NOTES

Leave yourself a good question.

What changed your mind? What would you try next?

Notes for Two kinds of completion

Notes are private to this browser and saved as you write.

A CHECKPOINT, NOT A SCORE

Can you explain the idea and try the exercise yourself?

Completion records your own assessment. It does not compile or test your C++.

Companion source 14 files