The same camera and scene are useful starting points for a device comparison. They are not enough to make the result comparable. The devices may resolve different quality profiles, use different shadow and water paths, prepare shaders at different times, or run with different presentation constraints.
OmiLith’s device history repeatedly comes back to that distinction. A build can compile while a device route remains untested. A screenshot can look correct while startup is still too slow. A selected mobile profile can be intentional rather than a missing desktop effect. A frame captured from an instrumented run can be valuable evidence without representing the clean shipping cost.
Resolve capabilities before executing a path
A feature needs more than a backend name. Storage formats, workgroup limits, sampling behavior, attachment support, and resource synchronization affect whether a concrete path is available. A capability result should select an implemented alternative with explicit limits.
This keeps fallback policy out of accidental failure handling. A simple atmosphere, water, or visibility path can be the correct selected route. It should preserve the meaning of the available scene inputs while stating which detail is absent. Silently attempting a full path and hoping the driver accepts it is not a capability system.
The Vulkan synchronization guide explains the underlying responsibility for ordering and visibility. WebGPU defines a different validation and resource model. A shared renderer can express the intended work, but each backend still has to implement its contracts. Sharing the word buffer does not make the lifetime and access rules identical.
Startup is part of the graphics experience
The later October history includes cold shader-preparation problems on browser, Android, and Xbox routes. The first usable frame is a user-facing milestone. Optional material variants or unused particle pipelines should not consume preparation time merely because an engine can construct them.
This led to several bounded-preparation changes in the recorded work. Some paths defer optional compilation; some preserve a minimal menu before entering a larger scene. The exact state matters: the tracker still retains open issues for particular Quest, phone, and Xbox qualifications. A merged startup fix does not imply that every large scene on every device is now accepted.
A mosaic should explain its differences
The five-device particle study labels portable and full tiers. That makes the image more useful than an unlabeled grid. The reader can ask whether the selected effects are coherent, rather than assuming a reduced effect is an unexplained regression.
Camera matching is still important. So are scene identity, asset revisions, view extent, projection, and settings. If one comparison intentionally changes only a diagnostic control, that isolation should be stated. If a water reflection strength differs between platforms, the difference belongs in the caption rather than being hidden beneath the term parity.
Measurements need a different record
The diary includes cases where GPU work improved but the whole route did not, and where a captured image passed a visual check while a high-percentile performance gate remained open. These are normal engineering outcomes. Reporting only the most attractive number would remove the information needed to decide the next step.
A useful performance record names the build, hardware, workload, selected profile, warmup, duration, and tracing state. CPU time, GPU time, presentation pacing, memory residency, and compositor drops answer different questions. A single screenshot cannot supply any of those distributions.
This is why the website keeps development videos and performance claims separate. A clip demonstrates a particular path visibly running. Qualification requires the accompanying evidence and its limitations. Cross-platform support becomes more credible when the remaining gaps are explicit, because the successful rows of the matrix then mean something precise.
References & further reading
Primary papers and documentation related to the techniques discussed here. Research references explain the background; the article describes implementation and validation at its dated checkpoint.
Have a thought or a question?
I'd love to hear it. ↗