QORPOUnreal shader stutter: a PSO playtest evidence plan
To investigate shader-related stutter in Unreal, test a packaged build through repeatable first-use events, record the cache and platform conditions, and capture timing evidence before assigning the cause. PSO precaching can address relevant compilation work, but enabling a setting does not prove complete coverage or explain every hitch.
A player enters a courtyard and the camera catches. The second visit feels smooth. That is a useful observation, not a diagnosis. The first visit may involve several kinds of work, and an average frame-rate number can hide the event the player noticed.
This article proposes an original test and evidence workflow. It is not a claim that a QORPO game has passed a PSO audit or that a particular engine switch eliminates all stuttering. It also makes no benchmark or hardware-performance claim.
Know what question PSO testing answers
A Pipeline State Object brings together rendering pipeline state. In its February 2025 technical explanation, Epic discusses driver compilation work and why precaching can reduce first-use stalls. It also describes tradeoffs and remaining complications. Read that as technical background rather than a guarantee for a specific project.
The practical question is narrower than “does the game run well?” Ask whether a defined visual event causes an unacceptable interruption under recorded conditions, and whether evidence points toward PSO preparation. Other loading, CPU or GPU work may need a different investigation.
Keep the symptom visible in the report. “A pause occurs when the courtyard effect first appears” is more useful than “Unreal has shader stutter”. It gives the team a location, event and comparison to investigate.
Record the build and rendering environment
Start with the packaged build identifier, engine version, platform, graphics API, device, driver version and relevant graphics settings. Include the test route and content revision. A route repeated on a different rendering configuration is not necessarily the same test.
Record the configuration actually used by the build. Epic's PSO Precaching documentation distinguishes precaching controls and notes support dependencies. Its current defaults and implementation details should not be assumed to match an older engine branch or every target RHI.
Keep the configuration record with the results. A screenshot of a setting in another project cannot establish what the tested executable used. If a value cannot be verified, mark it unknown and resolve it before claiming the feature was validated.
Define cache conditions precisely
“Cold run” can mean different things to different testers. Describe which relevant caches were present or reset, what installation state was used and whether the route had already been visited. Use documented, controlled test procedures appropriate to the platform.
Do not ask players to erase arbitrary folders as a universal troubleshooting method. This is a developer test plan, and clearing data can affect unrelated state or change the question being measured. Keep test data separate from real user progress and retain recovery information where needed.
Create paired observations: a defined first pass and a repeat pass under the same configuration. The difference can help locate first-use work, but it does not by itself prove that compilation caused the difference. Preserve that distinction in the report.
Build a route around first-use events
Choose a short route with events the player is likely to encounter: entering a scene, seeing a material variation, triggering an effect or opening an interface. These are candidate events, not claims that every one requires the same PSO behaviour.
Write the route as a sequence another tester can repeat. Keep camera direction, starting state and deliberate actions reasonably consistent. Add event markers where the tooling allows them, so a recording and trace can be compared without guessing which courtyard entry was the important one.
Original model example: a lantern effect. A fictional team records a route where a player opens a door and sees a lantern effect for the first time. A hitch appears on the first pass but not the repeat. The report retains both runs, configuration and trace timestamps. The team investigates the rendering event before deciding whether to adjust precaching, content or another system. This describes no actual studio result.
Capture timing rather than relying on average FPS
Epic's Unreal Insights overview describes a telemetry and analysis suite for project performance. Use the capture setup suitable for your build and question. Confirm that the needed trace data was recorded before scheduling a long test session.
Inspect the relevant time interval rather than presenting an entire session as one average. Keep a short video alongside trace evidence so the player-visible interruption remains connected to the technical event. If there is no trace showing the suspected work, write that the cause remains unconfirmed.
A useful report separates observation, hypothesis and decision. Observation: a first-pass hitch at a named event. Hypothesis: PSO preparation may be involved. Decision: gather or inspect the corresponding evidence. These are different statements, and combining them too early can send an engineer toward the wrong fix.
Check coverage and readiness, not just enablement
A setting being enabled is a configuration fact. Whether relevant work was prepared before first use is an outcome to validate. Review the diagnostic facilities documented for the exact engine version rather than copying an unverified command list from a forum.
Epic's precaching guide discusses validation and different preparation scenarios. Use that information to formulate project-specific checks, then preserve their outputs. Avoid declaring a whole game covered because one route no longer hitches after it has warmed the local cache.
Pay attention to loading feedback too. If preparation delays entry, inspect what the player sees and can do during that wait. Removing one visible pause while creating an unexplained wait elsewhere is a change in experience, not automatic proof of improvement.
This is distinct from our asynchronous loading guide. Both concern perceived interruption, but they investigate different work and require different evidence.
Compare a change without moving the baseline
After a candidate fix, repeat the same route and documented conditions. Change one relevant variable at a time where practical. If the content, driver and build settings all changed, acknowledge that the comparison cannot isolate one cause.
Review resource and experience tradeoffs alongside timing. A proposed change may affect preparation time, memory or visual presentation. Measure the effects that matter on the intended target; do not turn an appealing desktop result into a claim about all supported devices.
Original model example: the report after a change. A fictional result might say, “The named first-use event did not reproduce its prior hitch in the recorded retest conditions; wider content coverage remains pending.” That is a useful bounded statement. “All shader stutter is fixed” goes much further than the evidence.
Use a small release matrix
Select platforms and configurations from the game's supported targets and available evidence. Add content routes based on new materials, effects or rendering changes. Do not fill the matrix with arbitrary combinations merely to make the report look extensive.
Record each case as passed within scope, failed or awaiting validation. Include the build, route, cache condition, evidence location and remaining uncertainty. Preserve failures as well as successful runs so later work does not mistake an omitted case for a pass.
The same discipline appears in our network-emulation testing guide and prototype versus production readiness discussion. The testing conditions define what the result can support.
Frequently asked questions
Does a smoother second run prove shader compilation caused the hitch?
No. It identifies a repeatability pattern worth investigating. Timing and diagnostic evidence are needed to support a specific cause.
Is enabling PSO precaching enough?
It establishes a configuration choice, not complete content coverage or acceptable behaviour on every target. Verify the actual build and relevant first-use events.
Should every hitch be fixed by changing PSO settings?
No. Investigate the work present during the interruption. Unrelated loading or gameplay work requires its own diagnosis.
Continue the performance investigation
Explore QORPO's development blog and the texture review checklist for another example of separating attractive content from measured runtime behaviour. Start with one reproducible interruption and a report that says exactly what is known.
Sources checked on 24 October 2026. Epic documentation is linked beside technical statements. The workflow and model scenes are editorial proposals, not evidence of completed project tests or an Epic endorsement.