Skip to content

The first power line is preceded by the CPU's tiers (hw.perflevelN name, cores, L2) - #1695

Open
oliverames wants to merge 2 commits into
seedds:mainfrom
oliverames:cpu-tier-log
Open

oliverames wants to merge 2 commits into
seedds:mainfrom
oliverames:cpu-tier-log

Conversation

@oliverames

@oliverames oliverames commented Nov 7, 2026 •

Copy link
Copy Markdown
Contributor

What and why

The power line's "% of it on performance cores" is task_ptime, Apple's own split. Apple renamed its core tiers with the M5 (old performance cores are now "super", a new middle tier is "performance"), so the share does not say which tier it counts on a given chip, and a drop in it (a game parked off the fast cores, as in the frame-step notes) is hard to read without knowing the chip.

This logs, once before the first power line, each tier from hw.perflevelN (name, physical and logical cores, L2) and the model:

[dm] [nvn] cpu tier 0 (0 = fastest): 'Performance', 2 physical / 2 logical cores, L2 16384 KiB
[dm] [nvn] cpu tier 1 (0 = fastest): 'Efficiency', 4 physical / 4 logical cores, L2 8192 KiB
[dm] [nvn] cpu: 2 tier(s) on iPhone19,4; ...

It is read-only: no behaviour changes. A note on reading the share together with mean clock is in docs/development.md.

Checked

Front ends

None: no front end has to act on this.

Docs

  • The note is in docs/development.md (a reading guide, not a finding about one game)
  • A chain tool changed: dmsh_chain.py --header was run and dm/gfx/nvn/dmsh_chain.h is part of the change. Not applicable: no chain tool changed.
  • No game files, keys or data extracted from a game in the change or the attachments

…me, cores, L2), so a run's performance-core share reads against its chip

The power line's 'on performance cores' share is task_ptime, and Apple renamed its core tiers with
the M5 (the old performance cores are 'super', a new middle tier is 'performance'), so the share
does not say which tier it counts on a given chip. An iPhone 19,4 logs Performance 2 cores,
Efficiency 4.
oliverames pushed a commit to oliverames/nxnative that referenced this pull request Nov 10, 2026
…me on an iPhone, and the phone restarts some minutes later (Mario Kart World 1.8.0, iOS 27.3 beta); open

On an iPhone 19,4 the picture stopped 2 to 3 s into a race, 184 s after launch, with the overlay at 0 fps, the process alive, no [RED] line and no GPU error. Every thread waited and none spun. The state dump has the replay thread in iokit_user_client_trap under res_commit (pool_res, with g_mu held by its caller and g_res_mu across the call) and the GPU's completion queue waiting for a mutex in post_complete, with the main fence at submitted 206262 / completed 206256.

Ending the app did not end the process. The system's stack report 15 minutes later still has it with one thread, NVN queue replay, in an uninterruptible kernel wait with a read-write lock held and a kernel thread blocked on it, and the phone at 7.2 GB wired and 34 MB free. The phone then restarted itself.

It happened twice in four runs of one build (main 04811a6 with PRs seedds#1709, seedds#1695, seedds#1262, seedds#1599 and seedds#1713 merged): in that race, and an hour later at the title's demo with no button pressed, 353 s after launch, with the same thread state. Both came in a scene load (1,840 allocations added to the residency set in 678 commits in the 300 frames before the second). With main's 6f50de0 and 12a44e0 added, four races did not freeze, which is too few to say it is gone. The game makes about five residency commits a frame in a race. No fix: the entry says what was ruled out, what the host could change, and what to collect from the phone (SIGALRM for the host's dump, then systemCrashLogs). The game note links it under Open.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation nvn NVN on Metal and its tests (dm/gfx/nvn, dm/gfx/tests)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant