OpenNOW PS5 (PPSA99082) presents only on view changes; older builds' continuous presents were likely padding residue #7501

Activity

1. pushkarreddyy commented on Oct 18, 2026

   

   pushkarreddyy

   on Oct 18, 2026

   Contributor

   More actions

   I am investigating this frame presentation stall on OpenNOW PS5 (PPSA99082) following #4855 and preparing a reproduction/fix branch.
2. babyhuey commented on Oct 18, 2026

   

   babyhuey

   on Oct 18, 2026

   Contributor

   More actions

   The same stall on NVIDIA, so it isn't specific to the Radeon. Windows 11, RTX 3080, WinLibs GCC 15.2, Release, main 13e48ed29, OpenNOW PS5 (PPSA99082, catalog zip matching its sha256), one 60 s run, title bar polled every 3 s:

   • The title bar reads FPS: 0.00 (3) at about 3 s and FPS: 0.00 (7) at about 9 s, then stays at 7 presents until the run ends. The process stays alive, with no throw, FATAL or UCRT report.
   • A screenshot at about 57 s shows the sign-in screen fully drawn ("Press CROSS to sign in with NVIDIA", "X SIGN IN / O CLOSE APP", "OUTPUT 3840x2160 / 120 HZ / SDR"). So the seventh present has a complete frame, and nothing is presented after it.
   • With APS5_TRACE_WAITS=1 no [waits] report is printed in 60 s: no instrumented equeue, semaphore, event-flag, address or condition wait completes after the first few seconds.
   • Its own data/opennow/media.log ends after qualifying its decode profiles (4K120 SDR, 4K90 SDR and 1080P60 SDR H.264 qualified=1; the HDR HEVC profiles qualified=0 error=ffffffff), and then it waits for sign-in.

   AI-assisted: yes
3. babyhuey commented on Oct 18, 2026

   

   babyhuey

   on Oct 18, 2026

   Contributor

   More actions

   Follow-up to my NVIDIA comment above: on the current build this looks like OpenNOW's sign-in screen being event-driven, not a presentation stall. Windows 11, RTX 3080, main c34e9d855.

   The title only presents when its view changes. In GPU mode its render loop (src/demo_renderer.cpp, run()) does if (draw(canvas)) { drawInterface(...); gpu::swap(); } else sceKernelUsleep(1000);. draw() in src/main.cpp returns false when nothing changed: if (!first && !searchChanged && !searchInput.open && memcmp(&previous,&v,sizeof(v))==0 && memcmp(&previousCloud,&cv,sizeof(cv))==0 && ...) return false;. On the idle "Press CROSS" screen nothing changes, so a handful of frames and then nothing is what the code asks for.

   Input confirms it (keys posted to the title's own window; AnyPS5's default bindings, so arrows = D-pad and Return = Cross):

   • It settles at 8 presents by about 4 s.
   • D-pad Down at 12 s: no change, as expected, since that screen has nothing to navigate.
   • Cross at 22 s: it starts the device-code sign-in (new worker threads and non-blocking connects in its own network.log) and draws the code page, "ENTER THIS CODE" with a QR code and "EXPIRES IN ... SECONDS". From then on it presents about once per second (13 frames at 26 s, 27 at 40 s), which matches the countdown changing once a second.
   • Along the way: the end-of-pipe marker, flip count and flip events all advance normally through frame 7. VideoOut's buffer labels are only ever cleared, and the title never asks for them. Delaying the idle storage flush to 30 s changes nothing. fix(agc): wake queue 0 when storage results are pending #7535 doesn't change the frame count either.

   So the question flips: why does 72c5eed1f present continuously at about 28 FPS on a static screen? One possibility I haven't tested: View and CloudView have padding bytes (View ends with two bools after an unsigned), and memcmp compares those too. If the copies that fill v and cv carry stack residue from host calls on the render thread, such as scePadReadState, the mutexes and Driver::Submit through swap(), the comparison could differ every loop depending on how AnyPS5 is compiled. That would fit the never-taken branches in Submit changing the result. Does that match what you see when you press a button on the stalled build, @LeandroLP23? cc @pushkarreddyy since #7535 targets this.

   AI-assisted: yes
4. LeandroLP23 commented on Oct 18, 2026

   

   LeandroLP23

   on Oct 18, 2026

   ContributorAuthor

   More actions

   @babyhuey yes, it matches here. The "stalled" build answers input. Radeon 860M, Windows 11 26300, the relinked OpenNOW from my earlier runs (a main that shows the 7-frame stop), with Cross sent through APS5_PAD_INPUT_FILE and tools/pad_input.py so it doesn't depend on window focus:

   time	presents (window title)
   10 s	7
   18 s	7
   18 s	pad_input.py ... cross
   22 s	13
   26 s	17
   30 s	21
   38 s	28

   After Cross it presents about once a second, and its network.log shows the sign-in sockets and a non-blocking connect (errno=36). So on current builds the sign-in screen is idle by design, as your reading of draw() says, and the title isn't stuck. (A key posted to the window while it sat unfocused behind others did nothing. AnyPS5 drops keyboard input without focus, so the pad input file was the way in.)

   That also fits what the bisect could never explain: removing never-taken branches from Driver::Submit brought the "rendering" back. That changes what is left on the render thread's stack, and with it the padding bytes your memcmp theory points at. I haven't checked the padding directly. Unless someone sees a reason to keep it, I'll retitle this as "OpenNOW presents only on view changes; older builds' continuous presents were likely padding residue" and close it, since nothing in AnyPS5 is stuck.

   AI-assisted
5. LeandroLP23

   changed the title [-]AGC: since #4855, OpenNOW PS5 (PPSA99082) stops presenting after 7 frames, also with APS5_PM4_RING=0[/-] [+]OpenNOW PS5 (PPSA99082) presents only on view changes; older builds' continuous presents were likely padding residue[/+] on Oct 18, 2026
6. LeandroLP23 commented on Oct 18, 2026

   

   LeandroLP23

   on Oct 18, 2026

   ContributorAuthor

   More actions

   Closing: AnyPS5 isn't stuck here.

   • OpenNOW's sign-in screen presents only when its view changes (draw() in its main.cpp returns false when nothing changed, as @babyhuey found), so a handful of presents and then none is what the title asks for on the idle "Press CROSS" page.
   • Sending Cross through tools/pad_input.py restarts presents at about one a second, with the sign-in sockets opening (numbers above). The same holds on NVIDIA.
   • The bisect to feat(agc): keep the last submissions per queue and dump them on a stall or crash #4855 and the never-taken branches in Driver::Submit changing the result fit memcmp reading padding bytes whose contents depend on what is left on the render thread's stack. I haven't confirmed that directly, but it doesn't change the conclusion: the title answers input.

   tools/title_run.py (#7264) reports such a screen as stalled. Its documentation now says so and how to tell it from a stuck title. Thanks @babyhuey, @pushkarreddyy and @fdfawef324 for looking into it.

   AI-assisted
7. LeandroLP23

   closed this as not plannedon Oct 18, 2026