MagicBeanDev/Longshot

Watch

Fork 98

WIP: feat(vk): motion vectors for rigid objects moved by their own matrix #617

Draft

ballotstomper wants to merge 3 commits from ballotstomper/Longshot:fix/rigid-object-motion into main

ballotstomper commented

2026-11-15 00:25:54 +00:00

First-time contributor

Type: feat · Risk: low · Tested on: Linux, RX 6750 XT (RADV) · Needs: Windows or NVIDIA with DLSS; main against this PR, interleaved

Why

With DLSS or FSR 3.1, things that turn or slide by themselves without bones get no motion vectors, so the upscaler
smears them. Kakariko's windmill is the clearest case: the pattern on its sails turns into a blurry coloured mess
as they spin. Actor motion (#59) covers skinned models only; a rigid object that the game moves by changing its own
object matrix was left with the camera's motion alone. No issue covers it (the tracker searched for ghosting,
windmill, motion vectors, DLSS and FSR); #484 is ghosting around Link and Navi with DLSS preset K, another case.

What changed

A scene draw with no joints, whose program reads its object block as far as the origin, is now followed frame to
frame like a one-bone actor. When its object matrix or origin differs from the frame before, it is drawn again into
the motion image with both poses, so the upscaler sees the motion. Draws that stand still add nothing. It is opt-in
with RX_VK_DLSS_RIGID=1.

vk: skin_check in gpu/vk/vk_draw.cpp sends a draw with no joints to temporal_note_rigid_draw when the vertex
program reads its object block (the shader's c4, NVN binding 1) to 0x4c and the block is bound that far; skinned
draws go on as before (the bone palette check moved after the joint check).
vk: temporal_note_rigid_draw in gpu/vk/vk_temporal.cpp reads the 3 x 4 matrix and the origin at the draw
(ub_read, as actor motion reads poses), takes the matrix only when its rows look like a rotation times one scale,
and keeps every pose for the next frame. A pose found unchanged in the frame before's sorted list costs one binary
search; a changed one is paired with the nearest copy of its model from the frame before (within 2 units) and becomes
a Skin carrying both poses.
vk: actor_motion swaps and sorts the rigid poses once a frame and draws the rigid skins with their own two poses,
outside the pairing by place. The status line adds "rigid draws N seen, M moved, K of them by their origin alone".
shaders: dlss_actor.vert has a format bit 512 (dlss_actor::kRigid): every vertex on bone 0 with weight 1. The
SPIR-V header is regenerated with glslang.
docs: RX_VK_DLSS_RIGID beside the actor motion switches in docs/development.md.

Measurements

Verdict: works: the windmill's sails get motion vectors and keep their pattern while they spin. Against main with
the switch on: the same fps in the second and third walks (41.6 against 41.75, 41.95 against 40.8), about 0.2 ms more
actor motion CPU a frame. The first segments after arrival are noisy on both builds; the first walk was lower with the
PR in both runs (38.9 and 33.1 against 40.7 and 41.5), not explained yet.

Hardware: Arch Linux (kernel 7.3.4), Mesa 26.2.7 (RADV), RX 6750 XT 12 GB, Ryzen 5 5600X, 16 GB RAM
Scene: Kakariko Village at noon (teleport, stand, three walks with teleports between); 2560x1440, render scale fixed at
100%, AMD FSR 3.1, frame generation off, fullscreen; recorder thread, parallel replay 3, submit and presenter threads
Method: scripted runs (kak_walk3_frames), each build rebuilt before its run: a warm-up on main, then main, PR, main,
PR; fps and p99 frame time per segment from the bench's summary, the mean of the two runs; actor motion CPU from the
renderer's status lines; RX_VK_DLSS_RIGID=1 set for all runs (main ignores it)
How to reproduce: arrive in Kakariko, look up at the windmill with DLSS or FSR 3.1 on, with and without
RX_VK_DLSS_RIGID=1 (and RX_VK_DLSS_DEBUG=motion to see the vectors)

fps / p99 ms (run 1, run 2)	Before: main @ `6c9edffe`	After: this PR @ `d2b88782`
stand	32.4 / 58.3, 43.8 / 29.1	38.6 / 47.2, 24.0 / 106.8
walk	40.7 / 37.0, 41.5 / 35.5	38.9 / 46.3, 33.1 / 49.9
walk2	39.5 / 38.6, 42.1 / 35.3	41.6 / 35.1, 42.3 / 35.7
walk3	41.4 / 38.9, 42.1 / 36.0	41.4 / 36.8, 41.8 / 36.7
actor motion CPU a frame (status lines)	0.66-0.89 ms	0.87-1.03 ms
rigid draws a status line (seen, moved)	-	0.45-1.8 M seen, 3-4% moved

The PR's second run started slowly (stand 24.0 fps with 4 frames over 100 ms, its walk 14.5 s long against ~11.8),
and main's first run's stand was low too (32.4): those segments follow the first load after a rebuild.

main:  [hos host] vk: status: 600 frames, the slowest 148.9 ms; VRAM 8.9 of 11.0 GB; AMD FSR 3.1: 427 frames drawn, 1 made, jitter +0.438 +0.389 px, actor motion 36486 draws in 403 frames (0.813 ms CPU a frame; poses 37573 read at the draw, 0 copied later), its images 95 MB, its own 218 MB
PR:    [hos host] vk: status: 600 frames, the slowest 103.6 ms; VRAM 8.8 of 11.0 GB; AMD FSR 3.1: 431 frames drawn, 1 made, jitter -0.000 -0.167 px, actor motion 50677 draws in 407 frames (0.868 ms CPU a frame; poses 37427 read at the draw, 0 copied later), its images 95 MB, its own 218 MB; rigid draws 597696 seen, 22470 moved, 6 of them by their origin alone

Earlier, against the switch off on the same PC and scene (this branch before its rebase: a1edfbe4 is 61d526a4 now,
47d3e6e0 is 2a34e02e):

	After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4	After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4 (run 1 / run 2)	After, RX_VK_DLSS_RIGID=1, profiled: this PR @ 47d3e6e0
walk3 fps	40.2	43.0 / 42.2	40.3
`temporal_note_rigid_draw`, share of user samples (walk3)	-	0.72% (~0.65 ms a frame over the workers)	0.21% (~0.19 ms)
windmill sails in the motion view	no motion of their own	moving

The second commit replaced the per-model maps with sorted lists, which took the rigid path from 0.72% to 0.21% of the
samples.

Motion vector values (RX_VK_DLSS_DEBUG=motion, red = |x|, green = |y| over 16 px) in the arrival shot, camera still
(screenshots in the comment below):

region	After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4, red max / mean	After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4, red max / mean
windmill sails	0 / 0	13 / 0.6 (green 11 / 0.4)
ground	0 / 0	0 / 0

Walking around Kakariko, about 1,500 rigid draws a frame are seen and 40-90 move (3-5%), so the camera's own motion
doesn't mark static objects as moving.

Flags and settings

One new switch.

Flag	What it is	Before this PR	After this PR	Effect	Helps / doesn't help / untested	Recommendation
`RX_VK_DLSS_ACTORS`	actor motion as a whole (existing)	on	on	`=0` now turns rigid motion off too	-	unchanged
`RX_VK_DLSS_RIGID`	motion vectors for rigid objects moved by their own object matrix	-	off (`=1` turns it on)	the windmill's sails and other matrix-moved objects stop ghosting under DLSS and FSR	helps the windmill on Linux RX 6750 XT with FSR 3.1; untested with DLSS, on Windows and on NVIDIA	off until main against this PR is measured on more hardware, then on

Testing

Tested: Linux, RX 6750 XT, Mesa 26.2.7, FSR 3.1: the windmill by eye with the switch on and off (the sails' pattern
stays readable through the spin with it on, smears with it off) and in the motion view; scripted Kakariko walks against main
@ 6c9edffe, interleaved, with the status line's counts; the game-free suite: 545 passed, 13 failed, 22 skipped, and the same 13 fail on main @
6c9edffe (test_appimage_player_build, test_bake_portability, test_cpm_discovery, test_crash_dialog, test_env_on,
test_lift_cleanup_error, test_linux_preflight, test_make_game_cache, test_pipeline_tour, test_readback_late,
test_vk_pgo, test_vram_budget_row, test_walk_key).

Not tested: DLSS (no NVIDIA card here), frame generation, Windows. Rigid objects other than
the windmill were not looked at one by one. Things animated inside the game's shaders (the gate banner, wind
vegetation drawn by mesh shaders) are not covered by this PR: their vertex buffers and object matrices stay the same
from frame to frame, and the motion comes from a clock in a shared constant block, so they need the game's vertex
shader run with the frame before's constants (a later PR). Runs on this PC hit GPU device losses (a gfx ring timeout,
the same page fault at 0x820000 read by the scalar data cache) with the switch on and off alike, and on main @ 6c9edffe
(the warm-up run of the measurement above, the same fault in its GPU dump); they are not from this change and are
being followed separately.

Must be tested:

Windows or Linux, NVIDIA, DLSS: arrive in Kakariko, look at the windmill with RX_VK_DLSS_RIGID=1 and without,
expecting the sails to keep their pattern with it and to smear without (by hand, or Test Farm: @Beanstalk nvidia,
Kakariko windmill with RX_VK_DLSS_RIGID=1 against unset, DLSS on)
Another PC, any GPU: main against this PR with RX_VK_DLSS_RIGID=1, two interleaved runs each in Kakariko, expecting
no fps loss beyond noise, the first walk after arrival in particular (lower with the PR in both runs here) (by hand)

Risks

What could break: with the switch on, a draw whose object block isn't a placement matrix could get wrong motion
vectors (the rotation-and-scale check is there to leave those alone); about 0.2 ms of CPU a frame across the replay
workers. With it off, nothing: the draw path returns before any of the new work.

Turning it off: leave RX_VK_DLSS_RIGID unset (the default), or RX_VK_DLSS_ACTORS=0 for all actor motion.

Compatibility: Nothing changes: no saves, options, cache or ABI changes.

Checklist

Everyone

One topic.
The title is a Conventional Commit (type(scope): description) of the status line's type.
Why gives the reason plainly and links the issues that fit (the tracker searched).
Measurements has a verdict, or one line saying why there is nothing to measure.
Testing names what was tested, what wasn't, and what must still be tested, where and how.
Rebased on current main.
python -I -B tests/run_all.py passes (any failure that also fails on main is named).
No game files, dumps, build output or generated files.
third_party/ untouched (a new folder with a PROVENANCE.md instead).
The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

When it applies

Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value.
Screenshots of the same spot, captioned like the Measurements columns, for a change that shows on screen.
The SPIR-V headers regenerated with glslang (a shader changed).
Docs updated.
Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (not yet: built on Linux only; the new code is standard C++ with no platform calls)

**Type:** feat · **Risk:** low · **Tested on:** Linux, RX 6750 XT (RADV) · **Needs:** Windows or NVIDIA with DLSS; main against this PR, interleaved ## Why With DLSS or FSR 3.1, things that turn or slide by themselves without bones get no motion vectors, so the upscaler smears them. Kakariko's windmill is the clearest case: the pattern on its sails turns into a blurry coloured mess as they spin. Actor motion (#59) covers skinned models only; a rigid object that the game moves by changing its own object matrix was left with the camera's motion alone. No issue covers it (the tracker searched for ghosting, windmill, motion vectors, DLSS and FSR); #484 is ghosting around Link and Navi with DLSS preset K, another case. ## What changed A scene draw with no joints, whose program reads its object block as far as the origin, is now followed frame to frame like a one-bone actor. When its object matrix or origin differs from the frame before, it is drawn again into the motion image with both poses, so the upscaler sees the motion. Draws that stand still add nothing. It is opt-in with `RX_VK_DLSS_RIGID=1`. - vk: `skin_check` in `gpu/vk/vk_draw.cpp` sends a draw with no joints to `temporal_note_rigid_draw` when the vertex program reads its object block (the shader's c4, NVN binding 1) to 0x4c and the block is bound that far; skinned draws go on as before (the bone palette check moved after the joint check). - vk: `temporal_note_rigid_draw` in `gpu/vk/vk_temporal.cpp` reads the 3 x 4 matrix and the origin at the draw (`ub_read`, as actor motion reads poses), takes the matrix only when its rows look like a rotation times one scale, and keeps every pose for the next frame. A pose found unchanged in the frame before's sorted list costs one binary search; a changed one is paired with the nearest copy of its model from the frame before (within 2 units) and becomes a `Skin` carrying both poses. - vk: `actor_motion` swaps and sorts the rigid poses once a frame and draws the rigid skins with their own two poses, outside the pairing by place. The status line adds "rigid draws N seen, M moved, K of them by their origin alone". - shaders: `dlss_actor.vert` has a format bit 512 (`dlss_actor::kRigid`): every vertex on bone 0 with weight 1. The SPIR-V header is regenerated with glslang. - docs: `RX_VK_DLSS_RIGID` beside the actor motion switches in `docs/development.md`. ## Measurements **Verdict:** works: the windmill's sails get motion vectors and keep their pattern while they spin. Against main with the switch on: the same fps in the second and third walks (41.6 against 41.75, 41.95 against 40.8), about 0.2 ms more actor motion CPU a frame. The first segments after arrival are noisy on both builds; the first walk was lower with the PR in both runs (38.9 and 33.1 against 40.7 and 41.5), not explained yet. Hardware: Arch Linux (kernel 7.3.4), Mesa 26.2.7 (RADV), RX 6750 XT 12 GB, Ryzen 5 5600X, 16 GB RAM Scene: Kakariko Village at noon (teleport, stand, three walks with teleports between); 2560x1440, render scale fixed at 100%, AMD FSR 3.1, frame generation off, fullscreen; recorder thread, parallel replay 3, submit and presenter threads Method: scripted runs (`kak_walk3_frames`), each build rebuilt before its run: a warm-up on main, then main, PR, main, PR; fps and p99 frame time per segment from the bench's summary, the mean of the two runs; actor motion CPU from the renderer's status lines; `RX_VK_DLSS_RIGID=1` set for all runs (main ignores it) How to reproduce: arrive in Kakariko, look up at the windmill with DLSS or FSR 3.1 on, with and without `RX_VK_DLSS_RIGID=1` (and `RX_VK_DLSS_DEBUG=motion` to see the vectors) | fps / p99 ms (run 1, run 2) | Before: main @ 6c9edffe | After: this PR @ d2b88782 | |---|---|---| | stand | 32.4 / 58.3, 43.8 / 29.1 | 38.6 / 47.2, 24.0 / 106.8 | | walk | 40.7 / 37.0, 41.5 / 35.5 | 38.9 / 46.3, 33.1 / 49.9 | | walk2 | 39.5 / 38.6, 42.1 / 35.3 | 41.6 / 35.1, 42.3 / 35.7 | | walk3 | 41.4 / 38.9, 42.1 / 36.0 | 41.4 / 36.8, 41.8 / 36.7 | | actor motion CPU a frame (status lines) | 0.66-0.89 ms | 0.87-1.03 ms | | rigid draws a status line (seen, moved) | - | 0.45-1.8 M seen, 3-4% moved | The PR's second run started slowly (stand 24.0 fps with 4 frames over 100 ms, its walk 14.5 s long against ~11.8), and main's first run's stand was low too (32.4): those segments follow the first load after a rebuild. ``` main: [hos host] vk: status: 600 frames, the slowest 148.9 ms; VRAM 8.9 of 11.0 GB; AMD FSR 3.1: 427 frames drawn, 1 made, jitter +0.438 +0.389 px, actor motion 36486 draws in 403 frames (0.813 ms CPU a frame; poses 37573 read at the draw, 0 copied later), its images 95 MB, its own 218 MB PR: [hos host] vk: status: 600 frames, the slowest 103.6 ms; VRAM 8.8 of 11.0 GB; AMD FSR 3.1: 431 frames drawn, 1 made, jitter -0.000 -0.167 px, actor motion 50677 draws in 407 frames (0.868 ms CPU a frame; poses 37427 read at the draw, 0 copied later), its images 95 MB, its own 218 MB; rigid draws 597696 seen, 22470 moved, 6 of them by their origin alone ``` Earlier, against the switch off on the same PC and scene (this branch before its rebase: a1edfbe4 is 61d526a4 now, 47d3e6e0 is 2a34e02e): | | After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4 | After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4 (run 1 / run 2) | After, RX_VK_DLSS_RIGID=1, profiled: this PR @ 47d3e6e0 | |---|---|---|---| | walk3 fps | 40.2 | 43.0 / 42.2 | 40.3 | | `temporal_note_rigid_draw`, share of user samples (walk3) | - | 0.72% (~0.65 ms a frame over the workers) | 0.21% (~0.19 ms) | | windmill sails in the motion view | no motion of their own | moving | | The second commit replaced the per-model maps with sorted lists, which took the rigid path from 0.72% to 0.21% of the samples. Motion vector values (`RX_VK_DLSS_DEBUG=motion`, red = |x|, green = |y| over 16 px) in the arrival shot, camera still (screenshots in the comment below): | region | After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4, red max / mean | After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4, red max / mean | |---|---|---| | windmill sails | 0 / 0 | 13 / 0.6 (green 11 / 0.4) | | ground | 0 / 0 | 0 / 0 | Walking around Kakariko, about 1,500 rigid draws a frame are seen and 40-90 move (3-5%), so the camera's own motion doesn't mark static objects as moving. ### Flags and settings One new switch. | Flag | What it is | Before this PR | After this PR | Effect | Helps / doesn't help / untested | Recommendation | |---|---|---|---|---|---|---| | `RX_VK_DLSS_ACTORS` | actor motion as a whole (existing) | on | on | `=0` now turns rigid motion off too | - | unchanged | | `RX_VK_DLSS_RIGID` | motion vectors for rigid objects moved by their own object matrix | - | off (`=1` turns it on) | the windmill's sails and other matrix-moved objects stop ghosting under DLSS and FSR | helps the windmill on Linux RX 6750 XT with FSR 3.1; untested with DLSS, on Windows and on NVIDIA | off until main against this PR is measured on more hardware, then on | ## Testing **Tested:** Linux, RX 6750 XT, Mesa 26.2.7, FSR 3.1: the windmill by eye with the switch on and off (the sails' pattern stays readable through the spin with it on, smears with it off) and in the motion view; scripted Kakariko walks against main @ 6c9edffe, interleaved, with the status line's counts; the game-free suite: 545 passed, 13 failed, 22 skipped, and the same 13 fail on main @ 6c9edffe (test_appimage_player_build, test_bake_portability, test_cpm_discovery, test_crash_dialog, test_env_on, test_lift_cleanup_error, test_linux_preflight, test_make_game_cache, test_pipeline_tour, test_readback_late, test_vk_pgo, test_vram_budget_row, test_walk_key). **Not tested:** DLSS (no NVIDIA card here), frame generation, Windows. Rigid objects other than the windmill were not looked at one by one. Things animated inside the game's shaders (the gate banner, wind vegetation drawn by mesh shaders) are not covered by this PR: their vertex buffers and object matrices stay the same from frame to frame, and the motion comes from a clock in a shared constant block, so they need the game's vertex shader run with the frame before's constants (a later PR). Runs on this PC hit GPU device losses (a gfx ring timeout, the same page fault at 0x820000 read by the scalar data cache) with the switch on and off alike, and on main @ 6c9edffe (the warm-up run of the measurement above, the same fault in its GPU dump); they are not from this change and are being followed separately. **Must be tested:** - Windows or Linux, NVIDIA, DLSS: arrive in Kakariko, look at the windmill with `RX_VK_DLSS_RIGID=1` and without, expecting the sails to keep their pattern with it and to smear without (by hand, or Test Farm: @Beanstalk nvidia, Kakariko windmill with RX_VK_DLSS_RIGID=1 against unset, DLSS on) - Another PC, any GPU: main against this PR with `RX_VK_DLSS_RIGID=1`, two interleaved runs each in Kakariko, expecting no fps loss beyond noise, the first walk after arrival in particular (lower with the PR in both runs here) (by hand) ## Risks **What could break:** with the switch on, a draw whose object block isn't a placement matrix could get wrong motion vectors (the rotation-and-scale check is there to leave those alone); about 0.2 ms of CPU a frame across the replay workers. With it off, nothing: the draw path returns before any of the new work. **Turning it off:** leave `RX_VK_DLSS_RIGID` unset (the default), or `RX_VK_DLSS_ACTORS=0` for all actor motion. **Compatibility:** Nothing changes: no saves, options, cache or ABI changes. ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### When it applies - [x] Numbers from the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value. - [x] Screenshots of the same spot, captioned like the Measurements columns, for a change that shows on screen. - [x] The SPIR-V headers regenerated with glslang (a shader changed). - [x] Docs updated. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (not yet: built on Linux only; the new code is standard C++ with no platform calls)

ballotstomper added 3 commits

2026-11-15 00:25:54 +00:00

feat(vk): motion vectors for rigid objects moved by their own matrix 61d526a412

perf(vk): rigid motion looks up the frame before's poses by sorted exact pose 2a34e02ecf

fix(vk): rigid motion skipped before any work when off, switch documented

CI / Conventional Commit title (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

Third-party parts / As their notes say (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

PR description / Description follows the template (pull_request_target) Successful in 4s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

d2b887823e

ballotstomper commented

2026-11-15 00:26:04 +00:00

Author

First-time contributor

Screenshots: the Kakariko arrival with the windmill in view, AMD FSR 3.1, RX_VK_DLSS_DEBUG=motion, camera still (RX 6750 XT, Linux). The motion view's red and green are multiplied by 4 and its blue background dropped, so small motion shows; nothing else is changed.

After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4 (61d526a4 after the rebase): the sails have no motion of their own.

After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4: the sails show their turn (red one way, cyan the other).

Screenshots: the Kakariko arrival with the windmill in view, AMD FSR 3.1, `RX_VK_DLSS_DEBUG=motion`, camera still (RX 6750 XT, Linux). The motion view's red and green are multiplied by 4 and its blue background dropped, so small motion shows; nothing else is changed. After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4 (61d526a4 after the rebase): the sails have no motion of their own. ![After, RX_VK_DLSS_RIGID unset: this PR @ a1edfbe4](https://git.magicbean.dev/attachments/717c6d53-7c1a-40ec-a9f4-15673791c077) After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4: the sails show their turn (red one way, cyan the other). ![After, RX_VK_DLSS_RIGID=1: this PR @ a1edfbe4](https://git.magicbean.dev/attachments/2f23544c-fe2d-4576-a9d5-3e969a9ae03b)

motion_off.png

25 KiB

motion_on.png

30 KiB

ballotstomper commented

2026-11-15 00:46:54 +00:00

Author

First-time contributor

Measured main @ 6c9edffe against this PR @ d2b88782 (RX_VK_DLSS_RIGID=1), interleaved after a warm-up on an RX 6750 XT: walk2 and walk3 the same fps (41.95 against 40.8, 41.6 against 41.75), actor motion about 0.2 ms more CPU a frame. The first walk after arrival was lower with the PR in both runs (38.9 and 33.1 against 40.7 and 41.5), not explained yet: added to Must be tested. The GPU device loss seen here also happened on plain main (the warm-up run, same fault). Still open: a Windows build (test request T-ZZJQ) and DLSS (T-39PN).

Measured main @ 6c9edffe against this PR @ d2b88782 (RX_VK_DLSS_RIGID=1), interleaved after a warm-up on an RX 6750 XT: walk2 and walk3 the same fps (41.95 against 40.8, 41.6 against 41.75), actor motion about 0.2 ms more CPU a frame. The first walk after arrival was lower with the PR in both runs (38.9 and 33.1 against 40.7 and 41.5), not explained yet: added to Must be tested. The GPU device loss seen here also happened on plain main (the warm-up run, same fault). Still open: a Windows build (test request T-ZZJQ) and DLSS (T-39PN).