Repository navigation
Testing and Known Issues
Last updated: 2026-10-13.
KytyPS5-v20261013 is the current release, built from 446b9f60. It is preview 2's source plus:
- a precompile time budget (
-Minutes) that compiles the shaders recorded play uses most first and continues later where it stopped, and-RecordedOnly; - a faster whole precompile: more, smaller compile processes, large compute modules first and compute variants spread over the workers (on the test PC about 3½ h -> 1 h 27 min);
- an opt-in background precompile while the game runs (
run-windows.ps1 -BackgroundPrecompile); - load-time pipelines built on several workers in parallel;
- the Qt launcher applying the package's
launch.jsonprofile and keeping settings it does not know; -
launcher.cmdworking when started from a PowerShell 7 window; - precompile power saving as an explicit option (
-EcoQoS); - Vulkan cache feedback in the opt-in pipeline-creation trace.
This build translates some shaders differently, so caches from earlier builds are not reused. It ships the Windows x64 package (KytyPS5-v20261013.zip), corresponding source and SHA256SUMS. Follow installation and boot.
Demon’s Souls preview 2 remains available, built from b3266317. It is preview 1's source plus four changes:
- native Windows paths for pipeline-cache files;
- pipeline-binary files saved and opened past the 260-character path limit;
- a cooler default for the optional precompile;
- an opt-in pipeline-creation trace for stall reports.
It ships the Windows x64 package, corresponding source and SHA256SUMS. Its shader-cache identity is unchanged from the previous build, so compatible caches are reused with the same GPU and driver.
This fork's main branch is level with upstream KytyPS5 main (as of 2026-10-13) and includes KytyPS5-v20261013. The Demon's Souls integration is based on an older upstream snapshot, so only upstream changes that fit it were taken into main: load exec, PlayGo plgx chunks, sceAgcSetNop, private-format byte sizes and a file-truncate system call alias. HDR output, the newer launcher layout and upstream's newer shader-recompiler and renderer changes are not part of this fork yet. Rebasing the Demon's Souls work onto current upstream is planned.
Demon’s Souls preview 1 is this fork’s first custom Windows release. Its tested source 635289e8 includes the complete Chen integration and general controller, cache, memory and build corrections. Windows x64, corresponding source with pinned dependencies and notices, and SHA256SUMS are provided together. Follow installation and boot.
The complete Chen source scope includes the original 75aa4b9e snapshot and eight later commits through e019e72d. The public vibration-intensity slider predates this update. Controller regression tests and intensity 100 in the profile do not establish a new physical-vibration observation in this preview. Earlier local physical feedback is kept in the historical run record.
Correction (2026-10-13): an earlier version of this section showed six area results. Those runs never reached the areas: the scripted route pressed its buttons during the logos, and every run measured the game's opening cinematic. The results are withdrawn. A corrected area test, with cutscenes skipped and each area verified from screenshots, will replace this section.
Verified on this build (Ryzen 7 7800X3D, RTX 5080, NVIDIA 591.86, Windows 11):
- 15-minute precompile: finished in about 17 minutes including the first-start preparation and stored 1,869 MB.
- Game start: the game started from the release ZIP and played its intro without a crash.
- Background precompile: it continued during a session (58 batches in 4½ minutes) and stopped when the game closed. A script reading the launch script's output returned when the game exited. Its effect on gameplay frame times has not been measured.
Demon’s Souls PPSA01341 version 01.007.000, RTX 5080, driver 591.86, Ryzen 7 7800X3D, Windows 11. The release ZIP was extracted fresh and started by double-clicking launcher.cmd, at the package defaults of 1920×1080 fullscreen. The test was set up as an upgrading user:
-
a compatible cache recorded with the previous build's source: 888 shader inputs, 803 pipeline recipes and 87.6 MB of driver caches;
-
a copied Boletarian Palace save.
-
First start. Shader-list and static-input preparation took about 80 seconds before the game window opened.
-
Previous cache. Reused: both driver caches and all recorded inputs loaded, and nothing was regenerated.
-
Title screen. 60 FPS.
-
Fog load after Continue. About 5½ minutes, the same as earlier builds.
-
Play. Mostly 56–60 FPS standing. Dips to 30–48 FPS and severe hitches when walking into new areas and when fights start.
-
Pipeline creation the game waited on. 738 creations of 100 ms or more, about 350 seconds in a 640-second session. The longest stalled frame was 76.6 seconds.
-
Exit. Normal (code 0). The cache grew to 2,300 inputs, 2,142 pipelines and 194 MB of driver caches.
-
CPU package power. Average 57.7 W, 95th percentile 65.4 W.
The tester's verdict was that loading and play felt the same as earlier builds. This release does not shorten loads or in-game hitches. On a later start with the grown cache, the tester reported a much shorter fog load; that run was not timed.
This section describes the published preview 1. The newer unreleased fullscreen checkpoint is recorded separately below.
The exact preview build reached the title, main menu, Continue/Continue Offline, and Nexus with Demon’s Souls PPSA01341 version 01.007.000 on an RTX 5080, driver 591.86. Screenshot comparisons verified player movement and camera response. The test ran 604.662 seconds and ended through a normal close request at its planned limit: exit 0, no device loss, no forced game cleanup.
The measured game client remained a fixed 1280×720 bordered window. A maximize request did not enlarge it. This measures the client window, not the guest’s internal raster. The test used fresh matching caches, on-demand recording, prefetch disabled, vibration intensity 100, and the supplied fog/culling overrides. Cold startup and Continue took minutes while pipelines compiled. See the preview run record.
A newer unreleased local candidate was tested with Demon’s Souls PPSA01341 version 01.007.000 on an RTX 5080, NVIDIA driver 591.86 and Ryzen 7 7800X3D. The captured client was 1920×1080 in borderless desktop fullscreen. This confirms the window extent; internal rendering resolution remains unverified. These results do not change preview 1’s measured configuration or certify its fullscreen behavior.
The first run, using fresh application caches, remained at the Bluepoint screen and closed normally after 498.290 seconds. A second run with the same executable, initial save and application-cache directory passed that screen and visibly reached Nexus character/world/HUD. It closed normally on request after 557.781 seconds. Both returned exit 0 without reported device loss. Neither used a full precompile; the host-global driver cache was not cleared.
The restart loaded 149 recorded shader inputs, 144 pipeline recipes and both application-managed driver-cache files. On exit it recorded 888 inputs and 803 recipes. These are loaded/saved counts, not counts of successful cache hits. The second run reached more content, so its duration is not a matched loading-speed comparison. New-content pipeline creation still included a synchronous compute creation span of 22.6 seconds and a coarse compile-associated frame pause of 47.4 seconds. Those spans include work and waits; no exclusive driver-compiler time or stable gameplay FPS is established. The earlier Bluepoint stall persisted after compilation stopped, and its cause remains unresolved.
In the initial fullscreen checkpoint, a separate Boletarian Palace save was prepared but not launched. Later area tests are recorded separately below.
Where the pauses come from, 2026-10-11. A traced run of a development build at the same settings reached Boletarian Palace 1-1. It recorded every pipeline creation the game waited on:
- Over 350 seconds the game thread waited on 742 creations, 224.5 seconds in total. The fog load after Continue is mostly this.
- They were built one at a time: about 0.41 seconds per compute pipeline and 0.20 seconds per graphics pipeline, with the slowest at 2.94 seconds.
- The thread was busy compiling (CPU time 95% of wall time) while the rest of the CPU was under-used.
The same path causes hitches when new areas or effects appear. A newer unreleased candidate builds missing pipelines in parallel during command recording; its separate test scope is below. The published previews retain serial creation.
An unreleased Windows candidate was tested with Demon’s Souls PPSA01341 version 01.007.000, RTX 5080, NVIDIA 591.86 and Ryzen 7 7800X3D. The client was 1280×720 windowed with Mailbox presentation. Validation, shader validation, dumps and RenderDoc were disabled; the existing on-demand recording, fog and culling overrides were retained. Original saves, settings and caches were preserved; tests used separate copies.
Missing pipelines now build on a load pool when command recording is active. Ordered recording waits preserve each draw or dispatch's pipeline; without recording, creation remains synchronous. Controlled runs of one experimental executable used the same starting save and application-cache copies. The serial replay first showed the world about 172–183 seconds after Continue Offline, versus 49–60 seconds with parallel creation. Ten-second capture intervals bound those observations. The global Windows driver cache was not isolated, so these are not fully cold-driver measurements or a guaranteed speed-up on other systems. An additional background-pressure policy showed no clear benefit and was removed.
The final-policy candidate reached Gates of Boletaria with player, HUD and world visible. Movement, camera changes, combat, healing and death/reload responded. A separate fresh-cache Nexus replay lasted about 29 minutes of mixed play and observation, with visible floor/step traversal and camera response. It included about 78 seconds of requested movement/action holds; it was not continuous movement for the whole session. A normal close during loading also exited successfully. All these runs closed normally without a detected device-loss report.
A later build of the same change also passed a fresh-cache Nexus check lasting 589.4 seconds: movement off the steps, lateral movement, camera response and healing-item use were visible, followed by a normal close. This was a short final-build smoke test, separate from the longer replay above.
First encounters still cause pauses. Complete rendering correctness, stable gameplay FPS, a full campaign, other GPUs and a 1080p performance improvement remain unverified. Thresholded compile and recording-wait logs overlap and cannot establish average FPS. These changes are not included in the published previews or currently published source. See the separate game record.
GPU execution of a new batched guest decoder or translator is a research option. The existing compiler cannot simply be moved by a setting. Vulkan performs native compilation/linking through pipeline creation; device-generated commands bind pipelines or shader objects already available in execution sets. From these API contracts, there is no standard device-side command that invokes the vendor pipeline compiler for arbitrary new guest shaders. See shader modules and device-generated commands.
Experiment result, 2026-10-11. A standalone research prototype translated small guest scalar programs into complete Vulkan compute shaders on the GPU. It is not part of any build. Each program was a straight-line sequence of 32-bit move, add, subtract, xor and multiply instructions; anything else was rejected explicitly.
The test system was an RTX 5080 with NVIDIA 591.86 and a Ryzen 7 7800X3D. On it, the GPU-generated shaders were:
- byte-identical to a CPU implementation of the same translation for all 4,112 accepted programs,
- valid under the SPIR-V validator,
- correct when executed: 528 of the 4,112 accepted synthetic programs were run and read back exactly, including overflow, borrow, literal and register-overwrite cases.
A deliberately broken translator still produced valid SPIR-V but failed execution. Execution checks are required, not just validation.
The GPU path did not reduce CPU cost. Translating one program on one CPU core took about 3 microseconds. The GPU took about 0.26 ms for the same work, counting upload, submission, synchronization and readback. With 16,384 programs at once, the GPU only matched one CPU core, and 16 CPU threads were about 6.7 times faster.
Translation is also not the expensive step. Creating a Vulkan pipeline from each tiny generated shader still ran on the CPU and took about 12 ms when the driver had not seen it before. With the driver cache warm it took about 0.04 ms.
Moving translation to the GPU therefore adds latency and leaves the dominant pipeline-creation cost in place. The CPU translator remains the supported path. Work continues on finer attribution of slow pipeline creation and on persistent cache reuse. This covered only the small instruction subset above, not real game shaders, so it is not a gameplay performance result.
The useful GPU prototype compared synthetic CPU/GPU results and included upload, synchronization and readback cost. Persistent compatible caches and finer attribution of cache lookup, translation, layout work and driver creation remain necessary. Shader-module identifiers can avoid regenerating SPIR-V on compatible driver-cache hits, with normal compilation fallback on a miss; support and integration have not been verified in this candidate. No GPU compiler is included in preview 1, and this research measured no benefit from one.
KytyPS5-v20261013, from its test above:
| Area | KytyPS5-v20261013 result | Remaining limits |
|---|---|---|
| Progression | Game start and intro from the release ZIP, 1280×720 windowed | Area gameplay not yet re-tested in this release (see the correction above) |
| Stutter | Not measured in gameplay for this release | Places the precompiled part does not cover still compile on first visit |
| Caches | New shader-cache identity | Caches from earlier builds are prepared again; an earlier precompile has to be run again |
| Display | 1280×720 windowed renders | Fullscreen 1920×1080 not re-tested in this release; windowed 1920×1080 on a 1920×1080 desktop can stay black |
| Scripts |
launcher.cmd, run-windows.ps1 and the precompile work from a normal folder |
A folder whose name contains [ or ] stops the scripts ("missing ...kyty_emulator.exe"); extract to a folder without brackets |
| Background precompile | Opt-in; continued the precompile during a session and stopped with the game | Gameplay frame-time effect unmeasured; untested on CPUs with fewer cores |
| Build checks | Windows: 28 tests, installation and --help; Linux (no Qt): 23 tests |
No macOS run; no Linux or macOS package |
Preview 2 shares preview 1's limits below. Its own test (above) adds and confirms:
| Area | Preview 2 result | Remaining limits |
|---|---|---|
| Progression | Continue → fog load → Boletarian Palace 1-1 play at 1920×1080 fullscreen | Combat beyond the first enemies, other areas and campaign progress unverified |
| Loading and performance | Fog load about 5½ minutes; mostly 56–60 FPS standing, severe hitches in new areas and fights | Caused by pipeline creation on the game thread; unchanged in this release |
| Caches | A compatible cache from the previous build was reused; the shader-cache identity is unchanged | Caches remain GPU- and driver-specific |
| Display | 1920×1080 fullscreen renders | Windowed 1920×1080 on a 1920×1080 desktop can stay black while the game runs; use fullscreen or a smaller window |
| Launchers |
launcher.cmd started from Explorer works |
Started from a PowerShell 7 window, Play fails ("Get-FileHash is not recognized"); the Qt launcher drops unknown settings from the shared C:\ProgramData\Kyty\Kyty.ini when it saves, so back that file up |
| Precompile | Defaults to the physical cores less one at reduced power; on the test PC, peak CPU power fell from 71 W to 50 W for the same work | A full precompile takes roughly twice as long (estimate); -FullSpeed restores the old behaviour |
| Build/package checks | Windows: 19 tests, installation, isolated loader start; Linux (no Qt): 19 tests | Hosted macOS build still fails; no macOS or Linux package |
In preview 1 and preview 2, starting launcher.cmd inside PowerShell 7 can make its Windows PowerShell child select incompatible inherited modules. Play then fails with "Get-FileHash is not recognized" before the game starts. Start the supplied launcher.cmd from Explorer for those versions.
A development correction resets the inherited module path only inside the launcher's batch scope, allowing Windows PowerShell to rebuild its own defaults while preserving the caller's environment. Isolated tests exercise the actual launcher entry point and Play/precompile command builders with both an incompatible first module and a normal parent. All four routes hash successfully after the correction; the failing-before cases and caller preservation are checked. This establishes command-chain behavior, not a gameplay or performance result. The correction is included in KytyPS5-v20261013; preview 1 and preview 2 do not have it.
Preview 2's Qt launcher can remove settings it does not recognize when saving a configuration created by another launcher version. Back up the settings file shown in the launcher before switching builds. This affects both global settings and settings for individual games. Restoring a whole older file can also restore validation, shader-dump or RenderDoc settings; compare individual values before restoring them.
A preservation correction has passed isolated Windows launcher tests. The tests cover unknown global and game values, known-value updates, reordered and removed game entries, new entries, empty configurations, and migration from an older relative game path to an absolute path. The correction is included in KytyPS5-v20261013. The backup guidance above still applies to preview 1 and preview 2. No gameplay or performance improvement is claimed from these configuration tests.
The Qt launcher of preview 1 and preview 2 does not apply the launch.json environment defaults used by the script launcher. This can make two launch routes behave differently even when their visible game settings match. For the published previews, use the supplied script launcher from Explorer when you need its packaged defaults; the PowerShell 7 limitation above still applies.
A development correction has passed isolated Windows tests using a real child process. It reads launch.json beside the selected emulator, accepts string-valued environment defaults, and keeps explicit inherited environment values. KYTY_LAUNCH_PROFILE=0 disables the profile in that corrected build. A missing profile preserves the existing launch behavior; an unreadable or malformed profile reports an error and allows another launch attempt. The profile's command metadata is not executed. These tests establish launcher behavior, not game compatibility or performance. The correction is included in KytyPS5-v20261013.
The table below describes the published preview 1; the separate local candidate is scoped above.
| Area | Verified result | Remaining limits |
|---|---|---|
| Progression | Title, main menu, Continue Offline and Nexus; movement and camera response | Combat, other areas, campaign progress and sustained traversal unverified |
| Loading and performance | Cold startup and Continue took minutes compiling pipelines | No stable gameplay FPS, complete frame distribution, matched improvement or warm-restart benefit established |
| Rendering | Nexus character, HUD and world visible | Shader-table binding and image-set refusal messages remain; complete rendering correctness, earlier flicker and cutscene-transition failures not proven fixed |
| Display | Fixed1280×720 bordered client confirmed | Maximize did not enlarge the tested client; fullscreen and internal raster dimensions unverified |
| Controller feedback | Controller regression checks pass; intensity 100 configured | No fresh physical feedback observed in the preview; rumble, waveform haptics, adaptive triggers, speaker output and latency need separate testing |
| First use and caches | Matching fresh cache used for direct game test; on-demand profile supplied | Complete script-first-use timing, complete offline coverage, cross-version reuse and measured cache-hit/warm benefit unverified |
| Build/package checks | Windows: 14 targets, 12 tests and installation; Linux: 15 targets and 14 tests; five GPU groups; isolated CLI/Qt startup | Linux gameplay, other drivers/GPUs and normal interactive Qt quit unverified; hidden Qt check used a controlled stop. The hosted macOS build failed at an unsupported memory-test identifier; no macOS package is supplied |
| Reconstruction/frame generation | No verified enabled backend or measured benefit in this preview | No DLSS or frame-generation performance claim |
The hosted macOS build configured successfully, then failed compiling PageManagerTests.cpp because MAP_FIXED_NOREPLACE was undeclared. Later test and packaging steps were skipped. This is separate from the completed local Windows and Linux checks; it is a recorded build failure, with no macOS compatibility claim.
The title-screen readings varied from 1–60 FPS; a cinematic 60 FPS sample does not establish gameplay 60 FPS. A newly viewed scene still showed low readings. The direct game launch did not measure the full first-use launcher preparation route. A menu, screenshot, save checksum or subset of tests cannot establish full playability.
Earlier experimental results remain in recorded runs. The 400.631-second historical Nexus replay remained laggy after warming; its thresholded logs omit faster frames and precise movement timestamps. It is separate from this released preview’s test. Earlier physical vibration belongs to the earlier controller-feedback build, with channel/trigger attribution unverified.
Successful pipeline reuse and its effect on gameplay still require measurements for the preview build. Existing logs and bounded cache experiments do not establish successful reuse for every requested pipeline or a reduction in Nexus movement stutters.
Loaded entry counts, bytes on disk and saved shader recordings show that data is available or was written. They are not counts of successful in-game cache hits. Repeated shader or program labels also do not establish that the complete requested pipeline state was identical. The current records do not provide that per-request mapping.
Compilation scope durations can include work and waits; they do not isolate the cause of each pause. Separate loading from controllable gameplay and record timestamps for repeated movement or camera actions. Thresholded slow-frame logs omit faster frames, so they cannot supply average FPS or a complete frame-time distribution.
For a reuse report, identify the exact executable/version, game version, GPU/driver, settings and whether the same data was reused on restart. Repeat the same location and actions before comparing results. Distinguish actual reported cache hits, when your build exposes them, from entries loaded or files saved. Follow your build's documented options and preserve original saves and caches.
Record the executable/version, game serial/version, GPU and driver, output resolution, presentation mode and relevant validation settings. For a cache comparison, repeat the same location and actions, distinguishing first encounter from restart with the same caches. Keep original saves backed up and use separate copies for area tests.
Measure frame times during controllable gameplay. Introductory-screen FPS and cache file size are useful observations, but do not establish performance in a map. Report visual progression, controller input and audio alongside any crash or hang result. When a test is stopped manually or by a deadline, identify that termination separately from an emulator crash.
Use GitHub Issues in modhollow/KytyPS5 for reports about a published version of this fork. Search for an existing report first and add new reproduction details there when appropriate.
Include:
- Published version/tag or commit and executable checksum if available.
- Game title, serial and game version.
- Operating system, CPU, GPU and driver version.
- Resolution, relevant settings, cache state and whether the save is new or existing.
- Steps to reproduce, expected behavior and the furthest point reached.
- Whether the process crashed, hung, was closed manually or stopped at a test deadline.
- A short diagnostic excerpt with the relevant failure and preceding messages.
Review diagnostic attachments for personal paths and credentials before posting. Do not upload game files, system modules, extracted shaders, keys, saves or driver caches. A report can describe the save’s progression state without distributing the save itself.
Open the GitHub game report form. If the form has no separate field for a detail below, put it in Extra notes. Copy this template to keep the information together. For unavailable or irrelevant values, write Unknown or Not applicable and explain why.
### Build and game
- Emulator repository / download link:
- Release tag or source commit:
- Executable SHA-256, if available:
- Game title, serial and installed game version:
- Last working / first broken build, if known:
### Test environment
- OS version and architecture:
- CPU; GPU and driver; RAM / VRAM:
- Output dimensions; window/fullscreen; presentation mode:
- Validation, patches and other changed settings:
- First encounter or warm restart; precompile status and cache origin:
- New Game or Continue; location and progression state:
- Controller model, USB/Bluetooth, intensity and observed feedback, if relevant:
### Reproduction and result
1. Start the listed build with the settings above.
2. Follow these steps:
3. Expected result:
4. Actual result and furthest point reached:
- Frequency and duration:
- How the session ended; exit code / device loss, if known:
### Diagnostics
- First relevant error and preceding messages, with personal data removed:
- Reviewed log / screenshot / video, or why diagnostics are unavailable:
- Related public report links and additional context:Describe what you observed separately from a suspected cause. For controller reports, say what you physically felt; ordinary rumble, waveform haptics, triggers and speaker output need separate descriptions when known. For performance reports, identify introductory screens versus controllable gameplay, and distinguish first-encounter compilation from a warm restart. Preserve original saves and caches; describe their state without uploading them.
For a feature or documentation request, explain the problem or use case, the desired result, alternatives tried and relevant build/game context. Keep each report focused on one problem so its reproduction and resolution can be tracked clearly.
Public reports are tracked on GitHub. Release notes will link public reports when a published change addresses them.
A separate unreleased Nexus experiment removed recorder waits before physical-device format capability queries. Those queries still called the driver synchronously. Four same-executable, copied-save, empty-emulator-cache runs did not show a clear loading or hitch improvement: fully drawn world/player/HUD intervals after Offline overlapped at about 74–87 seconds for the original scheduling and 74–92 seconds for the experiment.
Required waits appeared at queue capacity and pipeline creation instead. A smaller named wait total does not by itself establish faster loading; thresholded and overlapping diagnostic spans cannot be added as elapsed savings or average FPS. The experimental bypass was not retained. Remaining first-use pauses and the existing compatibility limits are unchanged.
The comparisons used 1280×720 windowed/Mailbox on RTX 5080 with NVIDIA 591.86; global driver-cache isolation was unverified. Capture intervals, an idle gap in one control and an initial foreground interruption in the final repeat limit the evidence. This is a bounded Nexus result, not a second-area, full-playability or steady-FPS result. Published source, previews and releases are unchanged.
A tester reported more than three hours of Windows preparation with zero completed shards and a growing queue of split retries. They said reverting the PowerShell script to Chen's version worked. The reported script enabled EcoQoS by default; the revert also changes automatic worker budgeting. The exact hardware, revisions and complete shard logs were unavailable, so the cause remains unconfirmed.
The script's completed count refers to fully completed shards, not saved pipelines. A partial shard can retain useful output and request two smaller retries. Increasing waiting and split counts therefore show retry expansion, rather than proving that the same workers never return. Individual shard logs report captured, left-out and shared pipeline counts.
An unreleased correction makes EcoQoS optional and schedules smaller retries before untouched roots. Both halves remain scheduled; partial output is not treated as completion, and terminal and fatal errors still end the run. Focused scheduling and power-policy regressions passed. Native input preparation completed normally with the bounded CPU budget in both power modes; Windows reported the requested default-off and optional-on settings. This check created no pipelines and does not establish complete offline preparation or gameplay.
Two bounded pipeline samples on Ryzen 7 7800X3D, RTX 5080 and NVIDIA 591.86 each saved 393 pipelines and left six out before retrying. First-root pipeline work was about 502 seconds without EcoQoS and 494 seconds with it. Both samples were stopped at a 15-minute deadline while a retry remained active. No slowdown was reproduced in the bounded comparison. Global driver-cache isolation was unverified; no full-run speed benefit or tester-specific resolution is claimed.
For published versions, see the existing Windows power option. The correction remains unreleased. Include the actual build, CPU/GPU/driver, worker settings and preceding shard messages in a report; preserve original data and omit game, shader, save and cache payloads from attachments.
An unreleased local experiment finishes compute pipeline capture before starting graphics recipe capture. In the earlier combined queue, faster graphics work could reach the driver's compression dictionary while expensive compute work was still running, leaving those compute binaries to be compiled again during smaller retries. The experimental ordering retains both retry halves, original work membership and overflow/error reporting.
One matched Demon’s Souls preparation subset and all its required retries retained the same 1,041 unique pipelines on both versions. Reported native pipeline phases summed to about 21 minutes 25 seconds for the original ordering and 8 minutes 48 seconds for the experiment. The first large work item still took about seven minutes on either version. A lighter subset did not improve: pipeline work took about 30.5 seconds originally and 31.5 seconds experimentally. The observed benefit is avoiding repeated costly compute work during retry splitting; a general first-shard speedup is not established.
These component timings exclude process setup, shader-input preparation, merging and recovery; they are not complete preparation wall times. One baseline exit-status receipt was unavailable. Its saved output was independently checked by native binary merging, then replayed successfully. Both merged subset stores replayed in about six seconds with no new captured pipelines or omitted work. This checks reuse of the tested inputs and device/driver, not complete-package upgrades or unseen runtime states.
The comparison used Ryzen 7 7800X3D, RTX 5080, NVIDIA 591.86, one process and three threads, with no EcoQoS request and fresh application caches. Global driver-cache isolation was unverified. No full-batch timing, gameplay frame-rate improvement or resolution of the external three-hour report is claimed. Published source, previews and releases are unchanged. See preparation coverage and timing.
An unreleased local diagnostic addition extends the existing optional pipeline attempt trace with Vulkan's own creation feedback. Synthetic compute and graphics checks on RTX 5080 with NVIDIA 591.86 produced identical outputs with tracing disabled, enabled, repeated, and with an existing feedback request. Four requests returned valid application-cache-hit feedback; Vulkan validation reported no errors. This checks diagnostic correctness, not game loading speed or frame rate. Published source, previews and releases are unchanged.
For a local build containing this addition, enable the existing
KYTY_PIPELINE_ATTEMPT_TRACE=1 diagnostic before starting the launcher. The added
PIPEATTEMPT fields distinguish:
-
feedback-requested: whether this diagnostic added a feedback request. -
feedback-valid: whether a successful create returned usable feedback. -
driver-duration-ns: the driver-reported creation duration; interpret it only when feedback is valid. A valid zero duration is possible. -
app-cache-hitandapp-cache-hit-known: the reported application-cache-hit bit and whether usable feedback exists.
A valid hit bit reports help from the application-provided pipeline cache. A cleared bit does not prove a cold compile: the driver may use its internal cache or omit the application-hit indication. Failed creates, compile-required results, unusable feedback and a caller's existing feedback request remain unavailable in this diagnostic. Unavailable zeros must not be counted as measured durations or cache misses. Existing wall and thread-CPU timings remain separate measurements.
The diagnostic is off by default and preserves pipeline flags, cache policy and caller-owned request chains. It uses the core Vulkan 1.3 feedback API. See the Vulkan feedback contract and cache-hit flag meaning.
An unreleased correction makes equivalent LF and CRLF source checkouts produce the same prepared-input producer identity. Previously, Git's checkout line endings could change that identity even when the committed sources were identical, causing compatible prepared inputs to be rejected. The correction normalizes CRLF before hashing and preserves the existing LF identity. It also covers existing CRLF checkouts without rewriting their source files.
Real Git checkout tests reproduce the original mismatch and pass with the correction. A source-content edit still changes the identity; unrelated files do not. The native utility also retains the canonical identity. Previously created inputs with a divergent CRLF identity should be regenerated for the corrected build, rather than relabeled. Other compatibility and integrity checks still apply.
This prevents unnecessary regeneration caused by checkout formatting. It is not a measured compilation or gameplay speedup, and does not establish reuse across actual source, device or driver changes. Published source, previews and releases are unchanged. See prepared-input compatibility.
A further unreleased local experiment offers each selected compute pipeline variant to the existing worker pool. Previously, all variants of a shader seed ran serially on one worker, leaving other workers idle during costly variants. The experiment keeps the selected work, existing worker limit, compute-before- graphics ordering and overflow reporting. A single worker has no parallelism benefit; the comparison below used one process and three workers.
One matched Demon’s Souls preparation subset and every required smaller retry retained the same 1,041 unique pipelines on both versions. The first work item took about 7 minutes 50 seconds originally and 5 minutes 21 seconds experimentally. Summed native-run durations for the subset and its retries were about 9 minutes 53 seconds and 7 minutes 25 seconds, about 25% lower in this comparison. These sums exclude fixture copying, scheduling, analysis and validation; they are not complete precompile-batch wall times.
Independent native merging consumed all seven saved work items on each side. Replay with empty initial claims reused all 1,041 pipelines, with no new captured or omitted pipelines. Replay took about 6.1 seconds originally and 7.3 seconds experimentally, so a warm-replay improvement is not established. A fresh lighter subset retained the same 269 pipelines and took about 37 seconds originally and 33 seconds experimentally. Individual costly calls can take longer while running together; lower total CPU cost or energy use is not established.
Roots and the lighter control started with empty application caches. Retries preserved their own earlier captures. Tests used Ryzen 7 7800X3D, RTX 5080 and NVIDIA 591.86, with no EcoQoS request. Global driver-cache isolation was unverified. No universal speedup, full-batch timing, gameplay improvement or resolution of the external three-hour report is claimed. Published source, previews and releases are unchanged. See parallel compute work.
An additional unreleased local experiment offers larger selected compute modules to the existing parallel worker pool first. Module word count is an inexpensive estimate of work, not a guarantee of driver compilation time. Equal sizes keep their prior order; selected pipelines, worker limits and single- worker ordering are preserved. No new user setting is required.
One matched Demon’s Souls subset and all its required smaller retries retained the same 1,041 unique pipelines. With one process and three workers, the sum of monitored run intervals fell from 388.74 to 366.99 seconds, about 5.6%. These intervals include process startup, monitoring and final verification checks, but exclude fixture copying, queue wait, analysis, merging and replay validation. They are not complete precompile-batch wall times. The sum of reported native compute and graphics phases fell from 369.500 to 346.932 seconds.
The first subset improved from 287.40 to 264.39 seconds. A fresh root-only repeat in the opposite comparison order improved from 288.03 to 256.38 seconds with the same 192 retained keys. That repeat was not another complete shard family. A lighter control retained the same 269 keys and took 26.04 and 26.03 seconds, effectively unchanged. Independent native merging and replay with empty initial claims verified all 1,041 pipelines on each version, with no new captured or omitted pipelines. Warm-replay improvement is not established.
Tests used Ryzen 7 7800X3D, RTX 5080 and NVIDIA 591.86 with no EcoQoS request. Fresh roots and the lighter control began with empty application caches; retries preserved their own earlier captures. Global driver caches were not controlled. This bounded result does not establish universal speedup, full-batch duration, lower CPU or energy cost, gameplay performance or resolution of the external three-hour report. Published source, previews and releases are unchanged. See parallel compute work.
A further unreleased local check distinguished prepared shader inputs from compatible saved pipeline binaries. The earlier build recognized its generated inputs as current. A scheduling change made those inputs stale for the new build while the same binary cache remained current. Actual regeneration then produced current inputs with the new producer identity. The generated input bodies matched byte for byte; the producer header changed as intended.
Both full input-generation passes admitted 28,742 input records and 78,412 pipeline recipes. Existing grouped resource-validation rejection diagnostics were unchanged, so this does not establish support for every shader. Replay of the selected subset, with empty initial claims, recreated the same 1,041 unique pipeline keys from saved binaries with no new capture or omitted work. The compatible original binary-store bytes were unchanged across the transition.
This checks native input readiness, regeneration and selected binary reuse on Ryzen 7 7800X3D, RTX 5080 and NVIDIA 591.86. Emulator input prefetch, gameplay, complete-batch duration and a speed improvement were not tested by this check. Published source, previews and releases are unchanged. See prepared inputs and saved pipelines.
This is a development change that is not part of any published preview. The emulator now records the shaders and pipeline setups a game builds into a local file next to its other caches. At the next start it rebuilds those pipelines before the game draws anything.
- Scope of a record. It belongs to one game, one emulator shader-compiler version, one GPU and one driver. If any of these changes, the record is discarded and rebuilt automatically.
- Privacy. The record stays on the user's machine and is never uploaded.
- Measured on one machine. Demon's Souls PPSA01341 v01.007.000 on an RTX 5080 (NVIDIA 591.86) with a Ryzen 7 7800X3D. A second start rebuilt about 385 recorded pipelines in under half a second. Up to the same point it then built none during play, and the tester reported that loading felt about ten times faster than the first start.
- Limits. A first visit to a new area still compiles on demand, and very large records would delay the first frame; background warming is planned next. Published source and previews are unchanged.
This development experiment was not retained. It built each missing pipeline with driver optimization disabled first, then replaced it with an optimized build in the background.
- Setup. Demon's Souls PPSA01341 v01.007.000 on an RTX 5080 (NVIDIA 591.86) with a Ryzen 7 7800X3D. Each run used its own empty NVIDIA shader disk cache, so the user's global driver cache was left untouched.
- Startup replay. One recorded set of 156 pipelines took 35.4 s with optimized builds and 35.2 s with unoptimized builds. Disabling optimization gave no measurable speedup on this GPU and driver.
- Cold area visit (Nexus). Unoptimized builds still cost about 0.87 s each when made one at a time. Built in parallel on 8 threads during the startup replay, the same pipelines cost about 0.23 s each. On this host parallel building is the useful direction, not skipping optimization.
- Limits. One GPU and driver, one title, local unreleased builds. Other GPUs or drivers may differ. Published source and previews are unchanged.
This development change follows the startup replay above and is not part of any published preview. The emulator no longer makes the first frame wait for the whole recorded set. Startup only loads the record, and the pipelines are rebuilt on background threads at below-normal priority. If the game needs one that is not ready yet, that one is built immediately or waited for, and nothing is compiled twice.
-
Measured on one machine. Demon's Souls PPSA01341 v01.007.000, RTX 5080 with NVIDIA 591.86, Ryzen 7 7800X3D.
- A record of 908 pipelines was rebuilt in the background in 1.7 seconds on 7 threads.
- The title screen ran at 60 FPS 24 seconds after start.
- Going from Continue to the Nexus built 1 pipeline on demand; the first visit had built 908.
- Limits. The first visit to an area still compiles on demand. The Nexus frame rate is unchanged by this. Published source and previews are unchanged.
These are development changes to the Demon's Souls shader precompile, not part of any published preview. All of it was measured on one machine: Demon's Souls PPSA01341 v01.007.000, an RTX 5080 with NVIDIA 591.86, a Ryzen 7 7800X3D (8 cores / 16 threads) and 64 GB of memory. Every run started from empty caches.
- Default settings use the CPU. The precompile used to run 2 processes of 3 threads, which kept only about 40 % of an 8-core CPU busy, and was on course for about 3.5 hours. It now fills the allowed cores, less one, with two-thread processes. The same first part of the work finished in about half the time at about 80 % CPU.
- The largest shaders compile faster. A few compute shaders that read many formatted buffers were turned into enormous programs: one became about 2 million SPIR-V words and took over 3 minutes to compile. The format decoding is now shared within each shader instead of repeated at every read. That roughly halves those compiles, and compute precompile time fell by about 29 %.
- Whole precompile, default settings: about 1 h 27 min. A second start then loaded into the Nexus at 55–60 FPS, with no compile pauses, and rendering looked correct.
- Quick option. The precompile now builds the shaders recorded play uses first. A new option builds only those: about 24 minutes. On the same Nexus route that gave 59–60 FPS and no compile pauses. Areas no recording reached still compile when first visited, or with a later full precompile, which keeps what the quick run made.
- Time budget. The precompile can now stop after a chosen number of minutes and continue where it stopped on the next run. The shaders recorded play needs first are ordered first, so a short budget covers the start of the game. On the same Nexus route a 15-minute budget (about 18.5 minutes including the shaders already running) gave the same smoothness as the whole precompile: six slow frames, the worst 0.3 s. A 5-minute budget left about 6–14 s of short pauses, mostly while loading. Later areas still compile when first visited until the precompile is run again.
- Tried and not kept: making face culling dynamic state. The driver already treated those pipeline variants as one, so it saved nothing.
- Limits. One GPU, one driver and one game. Older precompiled caches do not match the new shaders, so precompile again after updating. Published source and previews are unchanged.