MagicBeanDev/Longshot

Watch

Fork 71

Longshot OOT #348

New issue

Open

opened 2026-11-14 03:14:08 +00:00 by Buasfe · 1 comment

Buasfe commented

2026-11-14 03:14:08 +00:00

Longshot version

v3.0.0-rc.3

Channel

Release candidate

What kind of problem

Low fps or stutter

What happened

Hey guys, I've been investigating performance issues on my RTX 3070 for a while now, originally with Hookshot and more recently Longshot. Unfortunately, Longshot has actually been performing considerably worse for me than some of my previous Hookshot builds.

In my latest test, I was literally just riding Epona around Hyrule Field without changing areas, and watched my FPS drop from roughly 30–35 to around 15. I decided to investigate it further with GPU pass timings and NVIDIA Nsight Graphics rather than assuming it was another VRAM issue.

With RX_VK_PASS_TIMING=1, I found that compute program 26fe0c70ab9fc547 became increasingly expensive throughout the session, reaching 21.499 ms per frame.

I used three Nsight captures and matched the program's SPIR-V against Longshot's shader cache. It appears to be a CMAA2-style screen-space edge-detection pass.

All three captures showed the same 108×60×1 dispatch dimensions, with 192 threads per workgroup. The shader reads a 3440×1440 colour image, generates edge candidates, and performs atomic operations on a small host-visible, host-coherent buffer.

I'm wondering whether atomic contention, increasing candidate counts or the memory placement of those counters could be contributing to the slowdown. I haven't confirmed the exact cause, so those are only hypotheses.

Interestingly, reported VRAM usage decreased while the shader's measured GPU time increased. The internal write-back and CPU-to-mirror operations were measured separately and accounted for much less time.

I know the pass-timing diagnostics introduce overhead, but the game was already performing badly before I enabled them.

I've also been carrying out quite a bit of investigation on Hookshot with Codex, including independent benchmarks of PRs #2826, #2774 and #2785, renderer and memory profiling, and an experimental fault-injection-tested patch for #2825. I'd like to share those findings separately as well, as I'm genuinely interested in contributing to the project.

I've got the full logs, benchmark reports, source patch and Nsight captures available. Happy to do any further testing if it helps narrow this down.

Where in the game

Hyrule Field, adult Link riding Epona without leaving the area

How often

Every time

Graphics card and driver version

NVIDIA RTX 3070 8 GB, driver 621.14

CPU, RAM and operating system

Ryzen 7 5800X3D, 32 GB DDR4, Windows 11

Changes from the defaults

Resolution: 3440×1440 ultrawide.
Upscaler: Off during the diagnostic run.
Frame generation: Off.
RX_VK_PASS_TIMING=1 enabled for GPU diagnostics only.
No RX_VK_IMAGE_PREALLOC override or other experimental Hookshot environment settings.
The slowdown also occurs without GPU pass timing enabled.

longshot_log.txt

Screenshots or video

No response

Before you send it

The problem is still there on the newest release or nightly.
I searched the open issues for it.
I'm not attaching game files, keys, the game's executable, its .bin caches or saves.

### Longshot version v3.0.0-rc.3 ### Channel Release candidate ### What kind of problem Low fps or stutter ### What happened Hey guys, I've been investigating performance issues on my RTX 3070 for a while now, originally with Hookshot and more recently Longshot. Unfortunately, Longshot has actually been performing considerably worse for me than some of my previous Hookshot builds. In my latest test, I was literally just riding Epona around Hyrule Field without changing areas, and watched my FPS drop from roughly 30–35 to around 15. I decided to investigate it further with GPU pass timings and NVIDIA Nsight Graphics rather than assuming it was another VRAM issue. With `RX_VK_PASS_TIMING=1`, I found that compute program `26fe0c70ab9fc547` became increasingly expensive throughout the session, reaching **21.499 ms per frame**. I used three Nsight captures and matched the program's SPIR-V against Longshot's shader cache. It appears to be a CMAA2-style screen-space edge-detection pass. All three captures showed the same 108×60×1 dispatch dimensions, with 192 threads per workgroup. The shader reads a 3440×1440 colour image, generates edge candidates, and performs atomic operations on a small host-visible, host-coherent buffer. I'm wondering whether atomic contention, increasing candidate counts or the memory placement of those counters could be contributing to the slowdown. I haven't confirmed the exact cause, so those are only hypotheses. Interestingly, reported VRAM usage decreased while the shader's measured GPU time increased. The internal write-back and CPU-to-mirror operations were measured separately and accounted for much less time. I know the pass-timing diagnostics introduce overhead, but the game was already performing badly before I enabled them. I've also been carrying out quite a bit of investigation on Hookshot with Codex, including independent benchmarks of PRs #2826, #2774 and #2785, renderer and memory profiling, and an experimental fault-injection-tested patch for #2825. I'd like to share those findings separately as well, as I'm genuinely interested in contributing to the project. I've got the full logs, benchmark reports, source patch and Nsight captures available. Happy to do any further testing if it helps narrow this down. ### Where in the game Hyrule Field, adult Link riding Epona without leaving the area ### How often Every time ### Graphics card and driver version NVIDIA RTX 3070 8 GB, driver 621.14 ### CPU, RAM and operating system Ryzen 7 5800X3D, 32 GB DDR4, Windows 11 ### Changes from the defaults - Resolution: 3440×1440 ultrawide. - Upscaler: Off during the diagnostic run. - Frame generation: Off. - `RX_VK_PASS_TIMING=1` enabled for GPU diagnostics only. - No `RX_VK_IMAGE_PREALLOC` override or other experimental Hookshot environment settings. - The slowdown also occurs without GPU pass timing enabled. ### longshot_log.txt s ### Screenshots or video _No response_ ### Before you send it - [x] The problem is still there on the newest release or nightly. - [x] I searched the open issues for it. - [x] I'm not attaching game files, keys, the game's executable, its .bin caches or saves.

longshot_log.1.txt

6 MiB

Buasfe added the

kind

bug

label

2026-11-14 03:14:08 +00:00

Buasfe commented

2026-11-14 03:18:15 +00:00

Author

Just wanted to add something else that might be useful.

I've also been doing quite a bit of investigation on the original Hookshot renderer with Codex, particularly around the VRAM and performance problems I've been experiencing on my RTX 3070.

We ended up building and testing several experimental versions, profiling renderer stalls, and independently benchmarking changes from PRs #2826, #2774 and #2785.

One of the more interesting findings was in the old Hookshot PR #2825. We identified a potential issue where a failed replacement allocation could leave an existing GPU-memory mirror unmapped while it still contained newer GPU-written data.

Codex helped put together a patch and fault-injection tests. The original failure was reproduced on the unmodified PR, and all nine targeted tests passed with the patch. We also successfully compiled the Windows Vulkan renderer and ran some in-game comparisons.

I haven't checked whether the same problem still exists in Longshot, so I don't want to suggest the patch is ready to merge or that it's related to the CMAA2 issue I'm reporting here.

I've got the source patch, test results and detailed investigation notes available if any of the developers would be interested in reviewing them.

I'd genuinely like to contribute more to the project, especially with testing and performance investigations on 8 GB NVIDIA cards. Happy to help however I can!

Just wanted to add something else that might be useful. I've also been doing quite a bit of investigation on the original Hookshot renderer with Codex, particularly around the VRAM and performance problems I've been experiencing on my RTX 3070. We ended up building and testing several experimental versions, profiling renderer stalls, and independently benchmarking changes from PRs #2826, #2774 and #2785. One of the more interesting findings was in the old Hookshot PR #2825. We identified a potential issue where a failed replacement allocation could leave an existing GPU-memory mirror unmapped while it still contained newer GPU-written data. Codex helped put together a patch and fault-injection tests. The original failure was reproduced on the unmodified PR, and all nine targeted tests passed with the patch. We also successfully compiled the Windows Vulkan renderer and ran some in-game comparisons. I haven't checked whether the same problem still exists in Longshot, so I don't want to suggest the patch is ready to merge or that it's related to the CMAA2 issue I'm reporting here. I've got the source patch, test results and detailed investigation notes available if any of the developers would be interested in reviewing them. I'd genuinely like to contribute more to the project, especially with testing and performance investigations on 8 GB NVIDIA cards. Happy to help however I can!

Buasfe referenced this issue from a commit

2026-11-14 04:27:44 +00:00

docs(vk): record the Hyrule Field slowdown and A/B plan

Buasfe referenced this issue

2026-11-14 04:27:46 +00:00

WIP: docs(vk): record the Hyrule Field slowdown and A/B plan #363