The412Banner beab4e7849 Performance: the client and game core masks, from Bannerlator's Linux session ...

A Steam session runs two things that want different cores at the same time,
and one affinity cannot serve both (Bannerlator cfca3912).

The client is the case that prompted it: Steam pins its own interface renderer
to a subset of cores it chooses - five of eight on one device, leaving out both
little cores and the fastest one - reasonable while a game is running and wrong
when the client is all there is, where it shows as Big Picture feeling sluggish.
BL_CLIENT_CPUS overrides it, re-applied on a beat by the session script because
steamwebhelper spawns children continuously and each inherits Steam's choice.
That block is Bannerlator's, verbatim. One deliberate difference: the client's
mask is sent whenever the override is on, even when it names every core,
because undoing Steam's pin is the whole point and the scheduler's default is
exactly what that pin takes away.

A game gets BL_GAME_CPUS instead, consumed by the Proton wrappers that r27
already carries, and as in Bannerlator it is sent only when it is a real
restriction: a list naming every core is what the scheduler does unaided.

Both live behind a Performance dialog with a checkbox per core, labelled with
its ceiling, and apply at the next session start.

2026-09-21 10:49:34 -04:00

..

src/main

Performance: the client and game core masks, from Bannerlator's Linux session

2026-09-21 10:49:34 -04:00

build.gradle

Every menu, dialog and overlay on Jetpack Compose

2026-09-19 16:05:54 -04:00