onion-mc/analysis/client-perf/research/r7-sable-create-client.md

Research: Client rendering cost of the Create/Sable stack (r7)

Scope: Sable 2.0.5, Create Aeronautics bundled 1.3.2 (aeronautics 1.3.2 + simulated 1.3.2 + offroad 1.3.2), SSRD 1.8.7, Sable: Physics Compat 1.3.0, Create 6.0.10 + Flywheel 1.0.6 (jar-in-jar), Slice & Dice, Dragons Plus, Enchantment Industry — on 1.21.1 NeoForge, Sodium 0.8.13, Iris 1.8.14-beta.1, DH.

Tag legend: VERIFIED = confirmed against the exact pinned jars in this repo (bytecode/config inspection) or an official spec; DOCUMENTED = official issue tracker/changelog/mod page; COMMUNITY = reddit/user comments; INFERENCE = my reasoning.

Summary

Sable does not have its own renderer — its only sub-level renderer (SODIUM_REACHAROUND) re-drives Sodium's own chunk renderer once per sub-level (own viewport, frustum, section meshing, layered draws), so each airship is effectively a small second terrain pass, and cost scales with number of sub-levels × their meshed section count, not with world render distance. The two biggest client levers are (1) shaderpacks: Flywheel's indirect and instancing backends both self-disable while a shaderpack is active (and this pack ships no Iris Flywheel Compat), dropping Create contraption rendering onto the vanilla block-entity path, and (2) per-frame pathological interactions (log spam on the render thread, per-tick sub-level-aware sound distance math) that produce the "FPS decays over 30–60 min" reports. Known FPS bugs in the trackers are mostly either fixed by our pinned versions (burner-sound degradation fixed in Aeronautics 1.3.0) or still open and unconfirmed on 2.0.5/1.3.2 (gradual decay while sub-levels exist).

Findings

A. How a Sable sub-level renders, and how it scales

1. Sable's sub-level renderer is a Sodium "reach-around", not a separate engine. sable-client.toml exposes exactly one renderer: sub_level_renderer = "SODIUM_REACHAROUND" (sole allowed value). Bytecode of mixin/sublevel_render/impl/sodium/SodiumWorldRendererMixin shows per sub-level: build a Sodium Viewport from the camera + sub-level container, compileSections (chunk mesh builds) honoring Sodium's performance.chunkBuildDeferMode/PrioritizeChunkUpdates, then draw via ChunkRenderMatrices + layered render types (VeilRenderType.LayeredRenderType) with ShaderInstance.setDefaultUniforms. Sub-levels also have their own frustum (cullingFrustum) and per-frame culling update. — VERIFIED (jar inspection; keys cross-checked in analysis/client-perf/data/observed-default-configs/sable-client.toml; Sodium integration also described in Sable's own README: https://github.com/ryanhcode/sable)
2. Cost model. Per frame each visible sub-level costs: one frustum+cull update, draws for all compiled sections in it (≈ ceil(blocks/16)³ worst case, typically the hull), plus matrix-only transform (movement itself is cheap — it's a pose, not a re-mesh). Re-meshing happens when blocks on the sub-level change (also piston/contraption edits). Scaling is roughly linear in count of rendered sub-levels and in meshed section count per sub-level, additive to normal world terrain cost; SSRD then decides how far away this pipeline runs. — VERIFIED (mechanism) / INFERENCE (exact per-sub-level ms; no public benchmark found)
3. Sable patches the shader stack it runs on. Sable 2.0.5 ships overrides of Flywheel's internal shaders (assets/flywheel/flywheel/internal/*, plus light/flat.glsl, light/smooth.glsl, light/smooth_when_embedded.glsl) so Create Flywheel visuals can be embedded in sub-levels; it has a sublevel_render.fancy.ProgramMixin and compatibility.flywheel.ShaderSourcesMixin. The vanilla core-shader override in the Sable stack is only worldborder.* from the nested Veil 4.3.2 jar (4 files) — the static scan's "sable overrides vanilla core shaders" is real but tiny in file count; the runtime shader patching (Veil/Flywheel) is the substantive interference surface. Iris compat exists explicitly (SableIrisCompat, compatibility.iris.ExtendedShaderMixin), and the pack additionally ships irisveil-0.3.0 (Iris Veil Compat). — VERIFIED (jar inspection; static scan in analysis/client-perf/data/jarscan-report.md)
4. Sable does not disable Sodium optimizations — the opposite: it requires Sodium (SSRD hard-requires it too) and reads Sodium settings (PerformanceSettings.chunkBuildDeferMode, PrioritizeChunkUpdates) to decide how sub-level rebuilds are queued; it changes no sodium-options.json keys. Known Sodium visual conflicts with Sable were fixed over time ("Fix some visual issues with Sodium on AMD machines" in 2.0.0; "Update Sodium compatibility to 0.8.13 alpha" in 2.0.0). — VERIFIED (jar inspection) + DOCUMENTED (https://api.modrinth.com/v2/project/T9PomCSv/version)
5. Client-cost toggles that exist in Sable 2.0.5 (all keys verified in SableClientConfig / observed defaults):

   key	default	perf relevance
   sub_level_dynamic_shading	true	adds dynamic_directional_shading mixins into ModelBlockRenderer/AmbientOcclusionFace/SectionCompiler (meshing-side cost for sub-levels)
   sub_level_skylight_shadows	false	if enabled, sub-levels cast world shadows — leave off
   sub_level_water_occlusion	true	hooks FogRenderer/GameRenderer/Camera
   sub_level_snapshot_interpolation_delay_ticks	1.5 (0–100)	interpolation buffer, not render cost
   sub_level_renderer	SODIUM_REACHAROUND	only value; no vanilla fallback to pick
   attempt_udp_networking	true	client side of UDP movement channel (disabling = "worse performance and latency" per common-config comment)
   Common config (SableConfig): sub_level_tracking_range (network distance of sub-levels to players), sub_levels_with_players_cannot_unload, sub_level_splitting*, disable_udp_pipeline, verbose_serialization_logging. — VERIFIED (jar inspection). Community advice to raise tracking range to 1280 (default 320) is about server→client streaming of sub-levels, not client frame cost: COMMUNITY (https://www.reddit.com/r/CreateMod/comments/1tdil1p/limiting_sublevel_render_distance_in_sable/ — key name sub_level_tracking_range verified in jar)

B. Known FPS issues / fixes in the Sable & Aeronautics trackers

6. Render-thread log spam can collapse FPS near any sub-level (Sable #881, open). A mod calling getEntityLookedAt() every frame produced huge AABBs against Sable's entity getter; Sable logged Aborting entity get for abnormally large AABB hundreds of times/sec, log4j ate ~75% of the render thread, 30→9–12 FPS. Root cause is the triggering mod (LegendarySurvivalOverhaul — not in our pack; only legendary-tooltips is, which does no entity lookups). Lesson for us: any per-frame entity/clip query mod can detonate on sub-levels; watch client logs for repeated Sable errors. — DOCUMENTED (https://github.com/ryanhcode/sable/issues/881)
7. "FPS decays over 20–60 min while a sub-level exists" (Sable #1011, open; Simulated-Project #746/#1204). Two distinct reported causes: (a) #1011 — gradual decay mitigated temporarily by F3+T (texture reload) or world rejoin, smells like a render-resource leak (Sable 1.2.2 era, unconfirmed on 2.0.5); (b) #746/#1204 — BalloonBurnerSoundInstance (aeronautics:block.hot_air_burner.head, aeronautics:block.steam_vent.head) re-played ~20×/s, each tick doing distanceSquaredWithSubLevels → projectOutOfSubLevel → getContaining → getLocalPlot → getChunk/getBlockEntity — hundreds of× vanilla cost; master volume 0 or blocking the two sound IDs stabilizes FPS. Fixed upstream: Aeronautics 1.3.0 changelog has "Fix performance degradation with Adjustable Burner sounds" → our 1.3.2 pin includes the fix. Caveat: 1.3.2 still contains BalloonBurnerSoundInstance with distanceSquaredWithSubLevels and AeroSoundDistUtil.tickGlobalBurnerSound — the sub-level-aware per-tick distance math is structurally still there, so treat "burners on many airships" as a known stressor. — DOCUMENTED (https://github.com/ryanhcode/sable/issues/1011, https://github.com/Creators-of-Aeronautics/Simulated-Project/issues/746, https://github.com/Creators-of-Aeronautics/Simulated-Project/issues/1204, https://api.modrinth.com/v2/project/oWaK0Q19/version) + VERIFIED (1.3.2 jar inspection)
8. Iris shader artifacts with sub-levels — affects our exact stack (Iris #3164, open). With Iris 1.8.14-beta.1 + Sable 2.0.x + Aeronautics 1.3.x + Sodium 0.8.13, physics structures render incorrectly with shaders enabled; artifact scales with structure size; any shaderpack; goes away with shaders off; specifically triggered by shader real-time shadows (Complementary/Miniature: disable shadows; Solas: disable SSAO). Root cause attributed to Veil; a community fix exists but is unmerged. Our shaderpacks/ = Complementary Reimagined + Makeup–Ultra-Fast, i.e. the affected families (Makeup–Ultra-Fast is also named in SSRD #50 "SSRD not working with Shaders"). — DOCUMENTED (https://github.com/IrisShaders/Iris/issues/3164, https://github.com/RanoldStranold/SSRD/issues/50)
9. Other tracker items (context, mostly visual or fixed): sub-levels invisible behind DH LODs at distance when tracking range > view distance (Sable #376); "Visual bugs with Sodium" world-invisible report (Sable #331, older Sable); Iris tessellation-shader geometry invisible with Aeronautics (Simulated-Project #308); IFC + flywheel:DEFAULT → invisible/transparent cogs & shafts (iris-flw-compat #244); resource leak of Contraption Diagram fixed in Aeronautics 1.1.0. — DOCUMENTED (https://github.com/ryanhcode/sable/issues/376, https://github.com/ryanhcode/sable/issues/331, https://github.com/Creators-of-Aeronautics/Simulated-Project/issues/308, https://github.com/leon-o/iris-flw-compat/issues/244, https://api.modrinth.com/v2/project/oWaK0Q19/version)

C. SSRD (1.8.7) — what it changes on the client

10. Config surface: a "Sub-Level Render Distance" slider injected into Sodium's video settings (below Simulation Distance); slider max is dynamically capped by your DH/Voxy LOD distance or the server maximum; server caps via /gamerule ssrdMaxRenderDistance (default 128 chunks) and /gamerule ssrdForceloadLimit (default 2 per player). SSRD 1.8+ requires Sodium 0.8 (we have 0.8.13 ✓) and DH or Voxy on the client. — DOCUMENTED (https://modrinth.com/project/fJ183v3D)
11. Cost & bugs: raising the slider = more sub-levels rendered by the full Sable/Sodium pipeline at distance (frame cost scales with visible sections, culling still applies), plus server-side force-loading pressure. Known issues: sub-levels visible through LODs with certain shaderpacks (Modrinth warning), DH fade-out also fades sub-levels (#64), zoom glitching (#66), Colorwheel incompatibility (#62, closed), various forceload/unload bugs (mostly closed as of 1.8.7). Mixins confirm the hooks: RenderSectionManagerMixin, SodiumConfigBuilderMixin (the slider), VanillaFrustumMixin/SodiumViewportMixin, RenderSystemFogMixin, DH DHShaderSourceMixin/FrameUniformsMixin, plus visual-distance mixins on contraption/entity/block-entity visuals. — DOCUMENTED (https://modrinth.com/project/fJ183v3D, https://github.com/RanoldStranold/SSRD/issues?q=is%3Aissue) + VERIFIED (SSRD-1.8.7-1.21.1.jar mixin list)
12. sablecompat (Sable: Physics Compat 1.3.0) only provides tags for modded blocks — no rendering behavior. Create Aeronautics: Compatibility 1.1.3 likewise compat glue. Neither is a perf surface. — DOCUMENTED (https://modrinth.com/project/sZbcIrJb; jar metadata)

D. Flywheel backend choice (Pascal NVIDIA vs Mesa RADV, with Iris)

13. Backend IDs & requirements (Flywheel 1.0.6, verified in source + jar): flywheel:off, flywheel:instancing (GL 3.3 + ARB_shader_bit_encoding; priority 500), flywheel:indirect (GL 4.6 + compute/DSA/ARB_multi_draw_indirect/SSBO/etc.; priority 1000 — GPU-driven culling with a depth pyramid + MDI; uses GL_KHR_shader_subgroup). DEFAULT picks the highest-priority supported backend, with a fallback log "Flywheel backend fell back from '{}' to '{}'". Driver special-case: Driver.INTEL gets indirect priority 1 ("Intel has very poor performance with indirect rendering, and on top of that has graphics bugs") — irrelevant to our fleet (NVIDIA Pascal, AMD/Mesa RADV). Both Pascal (GTX 10xx) and Steam Deck RADV advertise GL 4.6 + the required ARBs, so DEFAULT → indirect on all three machines when no shaders. — VERIFIED (Flywheel Backends.java @ Engine-Room/Flywheel branch 1.21.1/dev, and bytecode in create-1.21.1-6.0.10.jar → nested flywheel-neoforge-1.21.1-1.0.6.jar)
14. With a shaderpack active, both backends self-disable: supported() = … && !ShadersModHelper.isShaderPackInUse() on both instancing and indirect → DEFAULT falls back to flywheel:off (vanilla block-entity path for all Create visuals). This is why the pack has no working Create-instancing under Iris. The documented fix is Iris & Oculus Flywheel Compat (IFC): "Flywheel will disable its optimizations when you are using shaderpacks. This mod forces Flywheel's optimizations to be enabled… render Create's entities using Flywheel Instancing with shaderpack enabled… significantly improve fps" — IFC 2.3.x supports Create 6.0.9 + Flywheel 1.0.6, needs Iris ≥ 1.8.1 (we have 1.8.14-beta.1 ✓); Create 6.0.10 is newer than the last tested 6.0.9 → verify before shipping. Our pack does not include IFC. — VERIFIED (Flywheel source) + DOCUMENTED (https://modrinth.com/mod/iris-flw-compat, https://github.com/leon-o/iris-flw-compat/issues)
15. Driver risk notes for indirect: AMD Windows has a confirmed driver crash in Flywheel's indirect path (atio6axx.dll, glBindBuffersRange/MDI; GPUOpen-Drivers #89, acknowledged in Create/Flywheel repos) — does not apply to our fleet (no AMD Windows machine; Steam Deck is Mesa RADV, which Flywheel explicitly detects as Driver.MESA and supports); Create #10191 reports indirect crashes with elevator pulleys on one user setup (fix: instancing), and some users report indirect crashes with Create 6 + certain setups. Pascal is generally the safest indirect platform; treat any "Create block crash" on a client as "switch backend to flywheel:instancing or flywheel:off first". — DOCUMENTED (https://github.com/GPUOpen-Drivers/AMD-Gfx-Drivers/issues/89, https://github.com/Creators-of-Create/Create/issues/10191, https://www.reddit.com/r/CreateMod/comments/1pogo4t/create_6_crashing_when_placing_a_block_other/)
16. flywheel-client.toml (verified defaults in pack): backend = "DEFAULT", limitUpdates = true ("instance update limiting with distance" — keeps distant contraptions from updating instances; leave on), workerThreads = -1 (0–4; parallelizes instance updates, needs restart; 4-core Zen2 Deck vs 8-thread 7700K/6700K → explicit 2 on Deck if update-thread contention shows up is a testable knob), [flw_backends] lightSmoothness = "SMOOTH" (values FLAT, TRI_LINEAR, SMOOTH, SMOOTH_INNER_FACE_CORRECTED; config comment: "May have a large performance impact" — SMOOTH adds per-vertex light interpolation in Flywheel's uber-shaders; FLAT is the cheap end; each value changes compiled shader permutations). — VERIFIED (observed-default-configs/flywheel-client.toml, LightSmoothness.class bytecode)

E. Create contraption rendering cost & the addons

17. Create 6 = Flywheel 1.0 (official changelog: "Now using Flywheel 1.0"); contraption/kinetic visuals are instances batched per material; indirect adds GPU culling+MDI so cost scales with visible instances, instancing costs CPU draw calls per material (fine for tens of contraptions, and it's what IFC re-enables under shaders). Without Flywheel (backend off, e.g. under shaders without IFC) every kinetic/contraption visual becomes a vanilla block-entity render — the classic "Create + shaders = CPU death" mode. — DOCUMENTED (https://wiki.createmod.net/users/changelogs/6.0.0) + VERIFIED (backend mechanics, above)
18. Sable × Create integration adds its own frame mixins: Sable 2.0.5 has 30+ compatibility.create.* mixins (ContraptionVisual, CarriageContraptionVisual, VisualizationEventHandler, flywheel Engine/RenderDispatcher/EmbeddedEnvironment/VisualManager mixins) so contraptions riding sub-levels render inside the sub-level pass with embedded lighting — contraptions on airships are therefore both Flywheel instances and embedded-environment draws; a big airship factory is the worst-case render target. — VERIFIED (sable-neoforge.mixins.json, jarscan: create-aeronautics 20 frame mixins, sable 127)
19. Slice & Dice, Dragons Plus, Enchantment Industry: no client-perf issue reports found in their trackers for 1.21.1/Create 6 (S&D mostly touches RenderLevelStage/Gui events per jarscan; no lag/fps issues surfaced). They add ordinary instance/BER content; cost scales with placed blocks like any Create addon. — DOCUMENTED (absence of evidence) — treat as "no known client perf issues found" for these three.
20. Sound-adjacent sanity note: Create 6.0.0 already caps boiler sounds ("Play at most four steam engine sounds at once per side"), but Aeronautics adds its own global sound instances; combined with Sable's sub-level-aware distance math (Finding 7) the sound engine is a real client-tick cost center on all machines — an easy benchmark axis (master volume 0 vs 100). — DOCUMENTED (https://wiki.createmod.net/users/changelogs/6.0.0) + Finding 7

Top levers (ranked)

#	Lever	Impact	Machine(s)	Risk	Confidence
1	Add Iris Flywheel Compat 2.3.x (test vs Create 6.0.10) or accept flywheel:off under shaders knowingly	H — restores GPU instancing for all Create visuals under shaders; without it shader users pay vanilla-BER cost for every cog/contraption	All, biggest on 7700K+1060 (CPU-bound) and Deck (4-core Zen2)	M — IFC lists Create 6.0.9 as last tested; visual glitches possible per iris-flw-compat #244	High (Flywheel source-verified behavior + IFC docs)
2	In shaderpack settings, disable real-time shadows/SSAO (Complementary Reimagined, Makeup–Ultra-Fast) or accept #3164 artifacts	H — removes documented sub-level rendering corruption and shadow-pass cost; shadows are the confirmed trigger	All shader users	L — pure shader setting	High (Iris #3164 reproduces on our exact versions)
3	Keep SSRD slider modest (e.g. start at 8–16 chunks, not the 128-chunk server cap) and don't forceload broadly	M–H — directly bounds how many sub-level sections the per-sub-level Sodium pass draws; also server load	Deck (GPU/VRAM-limited) & 1060 6GB first	L — slider is the intended knob; gamerule cap on server	Medium-High (mechanism verified; magnitude unbenchmarked)
4	Prefer flywheel:indirect (DEFAULT) without shaders; only drop to flywheel:instancing on crash; consider lightSmoothness = "FLAT"/TRI_LINEAR on Deck if Flywheel shader cost shows in F1	M — indirect = GPU-culled MDI; FLAT removes per-vertex light smoothing cost ("large performance impact" per config)	Deck (RADV) and 1060 for lightSmoothness; indirect OK on Pascal & RADV	L–M — changing lightSmoothness alters visuals (block light smoothing)	Medium-High (config semantics verified; perf delta unbenchmarked)
5	Keep sub_level_skylight_shadows=false, keep limitUpdates=true, keep UDP networking on; watch client logs for Sable "Aborting entity get" spam (Finding 6 class)	M — avoids enabling the shadow pass; avoids the documented render-thread log-stall class	All	L	High (defaults verified; #881 mechanism documented)
6	If gradual FPS decay reproduces on 2.0.5: test F3+T / master-volume-0 as diagnostics (sound-engine vs render-resource); keep an eye on Sable #1011	M — separates the two documented decay causes cheaply before deeper profiling	All; 8GB-RAM 1080 Ti machine most sensitive to leaks	L — diagnostics only	Medium (both causes documented on adjacent versions; 1.3.2 fixed the burner one)

Open questions to verify by benchmark

1. ms/frame cost of one idle sub-level vs an identical static structure in the world (isolates the per-sub-level Sodium re-drive overhead), and the marginal cost of the 2nd, 3rd, 4th sub-level (linearity of Finding 2).
2. Cost of a moving + rotating sub-level with sub_level_dynamic_shading=true vs false (does rotation re-mesh? how often?) — deck vs 1060.
3. Frame cost of the same airship under shaders with IFC on vs off (instancing-merged vs vanilla-BER fallback) on 7700K/1060 and Deck.
4. flywheel:indirect vs flywheel:instancing vs off on RADV/Steam Deck specifically (Mesa GL4.6 MDI perf is the wildcard; also VRAM headroom vs the 1080 Ti's 8 GB-free-RAM host).
5. SSRD slider sweep (4/16/32/64 chunks) with DH LODs: frame-time and chunk-build queue behavior (Sable reads chunkBuildDeferMode=ALWAYS — does sub-level remeshing starve behind deferred world builds?).
6. Sound-engine axis: master volume 0 vs 100 near N burners/steam vents on 1.3.2 (residual per-tick distanceSquaredWithSubLevels cost, Finding 7).
7. Long-run decay test (45+ min, sub-levels present, #1011 class) on Sable 2.0.5 — does it still exist? Track client RAM/VRAM and F3+T recovery.
8. IFC 2.3.x × Create 6.0.10 × Iris 1.8.14-beta.1 compatibility spot-check (invisible cogs #244 class) before adding it to the pack.

Sources

Kept:

• Sable repo/README (https://github.com/ryanhcode/sable) — primary source; mixin list & Sodium integration verified against jar
• Sable issues #881, #1011, #376, #331 (github.com/ryanhcode/sable) — documented FPS failure modes
• Simulated-Project #746 + #1204 (github.com/Creators-of-Aeronautics) — sound-engine FPS decay, spark profiles, bytecode-level root cause
• Aeronautics changelog API (https://api.modrinth.com/v2/project/oWaK0Q19/version) — "Fix performance degradation with Adjustable Burner sounds" in 1.3.0
• SSRD Modrinth page + GitHub issues (https://modrinth.com/project/fJ183v3D, https://github.com/RanoldStranold/SSRD/issues) — config/gamerules, Sodium-0.8 requirement, shader caveats
• Iris #3164 (https://github.com/IrisShaders/Iris/issues/3164) — repro on our exact version stack; shadow trigger
• Iris Flywheel Compat Modrinth page (https://modrinth.com/mod/iris-flw-compat) — shader-mode Flywheel behavior + IFC support matrix
• Flywheel Backends.java (raw.githubusercontent.com/Engine-Room/Flywheel/1.21.1/dev) — backend support conditions, Intel deprioritization
• GPUOpen-Drivers/AMD-Gfx-Drivers #89, Create #10191, r/CreateMod threads — driver-level indirect risks
• Create 6.0.0 changelog (https://wiki.createmod.net/users/changelogs/6.0.0) — Flywheel 1.0 baseline
• Local pinned-jar inspection: sable 2.0.5 (+ nested veil 4.3.2), create 6.0.10 (+ nested flywheel 1.0.6), aeronautics bundled 1.3.2, SSRD 1.8.7, observed default configs (analysis/client-perf/data/observed-default-configs/)

Dropped:

• Modders-of-Create/Create-Aeronautics #14 "Gradual drop in fps" (404 — repo/issue no longer resolvable; superseded by Simulated-Project #746/#1204)
• r/CreateMod "Limiting sublevel render distance in Sable" full thread (login-walled; snippet retained only as COMMUNITY corroboration; its ticking_range key name is stale — actual key verified as sub_level_tracking_range)
• mcmod.cn Flywheel page (secondary aggregator; its AMD-Windows advice superseded by GPUOpen issue #89)
• 9minecraft/deepwiki Flywheel articles (SEO/aggregator content, no unique facts)

Gaps

• No public benchmark quantifies per-sub-level frame cost or scaling with count/size — the cost model in Finding 2 is mechanism-derived, not measured.
• Could not confirm whether Sable #1011 (gradual decay, F3+T-reset) still reproduces on Sable 2.0.5 — issue is open but filed against 1.2.2; no maintainer root-cause posted.
• IFC compatibility with Create 6.0.10 specifically (last tested 6.0.9) is unverified; nor is IFC × Sable 2.0.5 embedding (Sable overrides Flywheel shaders, IFC also patches them — interaction untested publicly).
• Shaderpack-specific behavior of Makeup–Ultra-Fast with SSRD (#50) and Complementary Reimagined with #3164 is reported for sibling packs (Makeup–Ultra-Fast plain, Complementary Unbound); Reimagined itself untested in those threads.
• Steam Deck (RADV) Flywheel-indirect reports are anecdotal in either direction; no RADV-specific issue was found, which is weak evidence of health, not proof.