[Tracking] Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces

This issue collects every open report of lighting problems (overexposure, bloom, crushed shadows, black faces), so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.

Summary

Problems reported:

areas washed out in white or overexposed (outdoors, the Deku Tree clearing, after Gohma);
bloom that is too strong or blocky;
shadows that are crushed black, dithered or striped;
faces or chest items drawn black;
Link drawn white or over-bright.

The bright red/green plant stems are a different bug, fixed in v2.0.6 (PR #759).

Affected GPUs and versions

GPUs: all vendors: GTX 1650 / 1660 Super, RTX 3060-5050-4090, RX 6700 / 6700 XT / 6750 XT, RX 9060 XT / 9070.
Versions: old builds to v2.0.5.

Evidence from the logs

Hookshot: Severe overexposure / bloom issue #36: overexposure and dark NPCs from the TAAU network on native coopmat; workaround RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1. v2.0.5 fixed dark or black faces (character lighting), so older reports here need a retest.
AMD RX 6700 XT (v2.0.5): Great Deku Tree clearing washed out in white haze (normal on v2.0.3) #914 (RX 6700 XT, v2.0.5): the Deku Tree clearing is washed out in white haze for a while (normal on v2.0.3); the log shows 16 views of a BC4 array as R16G16B16A16_UINT not made.
Still very dark shadows, textures and very very bright blooming vegetation #812 (RTX 4090, v2.0.5): flags very dark, black dithered owl shadows, very bright vegetation.
RX 9060 XT (Windows Vulkan): Blocky/pixelated light bloom, overblown lighting glare, and black textures in opening scenes / Kokiri Forest #606 (RX 9060 XT): blocky light halos, overblown bloom, crushed black under bridges.
Black faces #947 (v2.0.5): black faces inside the Deku Tree after re-preparation.
Shadows going crazy in Hyrule Field (later in Castle Town - Video) #468 / The lighting and shadow issues in Hyrule Field #515: striped shadows in Hyrule Field; PR vk: mesh programs with control topology 1 draw points, with the point sprite coordinate (grass shadow mesh on AMD, #302) #482 (low-vram) fixed one cause. v2.0.6 also includes PR BC3 re-encode of ASTC arrays: one layer a run (Hyrule Field grid lines) #956, which fixes the dark tile outlines on Hyrule Field's terrain seen from a distance and may be part of Shadows going crazy in Hyrule Field (later in Castle Town - Video) #468.
Gerudo Valley Graphics #943: neon graphics at the Gerudo Valley entrance.

Workarounds

RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1 (Hookshot: Severe overexposure / bloom issue #36).

Reports merged here (17 issues, about 28 people)

Issue	Title	People	GPU	Version	Key detail
#36	Hookshot: Severe overexposure / bloom issue	7	RTX 4080S, RX 9060 XT, RTX 3080 Ti, GTX 1650, RTX 3060	old	Overexposure/white-out outdoors (RX 9060 XT, exposure 1.0) + dark NPCs/shadows (TAAU network on native coopmat, workaround RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1); v2.0.…
#515	The lighting and shadow issues in Hyrule Field	4	?, RTX 5060 Ti	v2.0.4	Hyrule Field: streaky flickering shadows (gone on low-vram per aatolSP) + glowing plants (still on v2.0.4, plancha2002) + crash inside the Citadel (aatolSP log)
#468	Shadows going crazy in Hyrule Field (later in Castle Town - Video)	2	?, Arc B390 Linux	low-vram	Shadow stripes in Hyrule Field/Castle Town (PR #482 in low-vram); B390 Linux can't test: segfault in ANV at first mesh draw (#748)
#723	Weird graphical bugs	2	RX 6700	v2.0.2	No more crash but many visual bugs (glow, overexposure dropping fps, flowers flickering pink/green, very dark rocks)
#280	Faulty graphics / textures / effects	1	RTX 5050	v2.0.3	Glitches mostly fixed on v2.0.2; new: foliage/flowers with bloom/glow that shouldn't have it (video, v2.0.3 screenshot)
#316	weird black lines on zelda's first appearance	1	?	foliage-linux-updater	Black lines on the ground at Zelda's first appearance (Lichii save); log attached; reporter asked for news (no maintainer reply on the log)
#508	After defeating Gohma, the Deku Tree appears overexposed.	1	?	compile-retry	After Gohma, Deku Tree exit overexposed, plants glow (log)
#557	add setting resolution graphic etc	1	?	?	Titled as a settings request but body: Link drawn white when waking up and in the Saria ocarina scene (v2.0.5 fixes dark/black faces; white Link see #224)
#606	RX 9060 XT (Windows Vulkan): Blocky/pixelated light bloom, overblown…	1	RX 9060 XT	honest-eta	RDNA4 Windows: blocky/pixelated light halos, overblown bloom, black crushed surfaces under bridges (gist log + screenshots)
#613	broken textures on amd 9070 link glows	1	RX 9070	honest-eta	Broken textures, Link glows (no details); v2.0.5 character lighting fix
#746	[AMD RX 6750 XT] Overexposed lighting on Link + heavy stutter at game…	1	RX 6750 XT	v2.0.2	Link overexposed, black screen before gameplay renders, stutter 29 fps (v2.0.5 character lighting fix)
#771	visual bugs, light issues and low fps	1	GTX 1660 Super	v2.0.3	Visual/light issues and low fps on v2.0.3 (log, screenshot); also #338 reporter
#782	Big chests opening with bad render of item	1	RTX 4090	v2.0.2	Big chest items rendered dark (Dodongo's Cavern); v2.0.5 character/compute lighting fix
#812	Still very dark shadows, textures and very very bright blooming veget…	1	RTX 4090	v2.0.5	v2.0.5 Kakariko: flags very dark, owl has rough black dithered shadows, vegetation very bright with bloom (2 logs)
#914	AMD RX 6700 XT (v2.0.5): Great Deku Tree clearing washed out in white…	1	RX 6700 XT (0x800161)	v2.0.5	Deku Tree clearing washed out in white haze for a stretch (normal on v2.0.3), then recovers; pixel-like vertical streaks in the blurred background (new in v2.0.5); 16 vi…
#943	Gerudo Valley Graphics	1	RTX 4070 Super	v2.0.5	Gerudo Valley entrance neon graphics (also v2.0.5 known: Gerudo terrain holes)
#947	Black faces	1	RTX 4060 Laptop	v2.0.5	Black faces inside the Deku Tree after re-preparation, wrong-coloured textures in Kokiri

Adding a report

Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: screenshot, place, GPU, version, and hookshot_log.txt.

All tracking issues

[Tracking] VRAM and RAM fill up over play time: fps fades, textures degrade or turn rainbow, a restart fixes it (mostly 4-8 GB cards) #993 Garbled / rainbow textures that get worse over play time (VRAM over budget, mostly 4-8 GB cards)
[Tracking] Floating trees, missing mountains and vanishing near vegetation #994 Floating trees, missing mountains and vanishing near vegetation
[Tracking] Low FPS with low GPU usage (CPU-bound), FPS drops in Castle Town / Hyrule Field, shader stutter #995 Low FPS with low GPU usage (CPU-bound), FPS drops in Castle Town / Hyrule Field, shader stutter
[Tracking] AMD on Windows: driver crash, device lost or freeze (RX 5000-9000, Deku Tree / after cutscenes) #996 AMD on Windows: driver crash, device lost or freeze (RX 5000-9000, Deku Tree / after cutscenes)
[Tracking] AMD handhelds and APUs (ROG Ally / Ally X, Legion Go, Radeon 780M/860M/890M): black screen, device lost, reboot #997 AMD handhelds and APUs (ROG Ally / Ally X, Legion Go, Radeon 780M/860M/890M): black screen, device lost, reboot
[Tracking] Black screen with audio after the intro / at the Deku Tree cutscene #998 Black screen with audio after the intro / at the Deku Tree cutscene
[Tracking] Intel Arc and Core Ultra iGPUs: device lost, black screen after the intro, Linux ANV crashes #999 Intel Arc and Core Ultra iGPUs: device lost, black screen after the intro, Linux ANV crashes
[Tracking] Linux and Steam Deck: GPU hangs, crashes, low FPS and build failures #1000 Linux and Steam Deck: GPU hangs, crashes, low FPS and build failures
[Tracking] GPUs without mesh shaders (GTX 9xx/10xx, RX 400/500/5000, Iris Xe/UHD): v2.0.6 fallback reports #1001 GPUs without mesh shaders (GTX 9xx/10xx, RX 400/500/5000, Iris Xe/UHD): v2.0.6 fallback reports
[Tracking] Invisible or missing objects, walls and effects #1002 Invisible or missing objects, walls and effects
[Tracking] Antivirus false positives on HookshotBuilder.exe (Defender Trojan:Script/Wacatac.H!ml) #1003 Antivirus false positives on HookshotBuilder.exe (Defender Trojan:Script/Wacatac.H!ml)
[Tracking] Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces #1004 Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces
[Tracking] Flicker and flashing: brightness pulses, one-frame flashes, doubled image with frame pacing #1005 Flicker and flashing: brightness pulses, one-frame flashes, doubled image with frame pacing
[Tracking] AMD rendering: white silhouettes, block squares / grid lines, no anti-aliasing (networks in software) #1006 AMD rendering: white silhouettes, block squares / grid lines, no anti-aliasing (networks in software)
Feature requests (collected) #1007 Feature requests (collected)

The overexposed lighting was fixed in 2.0.5, but returned in 2.0.6

Outside Zora Town: Water Fall issues on AMD,

Version: v2.0.11
GPU: AMD Radeon RX 9060 XT
CPU / RAM: Ryzen 9 5950X, 32 GB
OS: Windows 11 Home

hookshot_log.txt

Water.mp4

Still happening on v2.0.11.

System: Ryzen 7 5700X3D · RTX 5070 Ti (NVIDIA driver 32.0.16.2114 / 621.14) · 32 GB RAM · Windows 11 Pro build 26300 · Vulkan. 100-180 FPS, performance fine.
Version: v2.0.11 (some screenshots taken on v2.0.10; resumed the same save in the same area on v2.0.11 hours later and the bugs are unchanged).
Progress: ~2+ hours in, young Link, Spanish language. Now on Death Mountain Trail.

Death Mountain Trail: big areas of rock/terrain render pitch black with hard edges, like broken shadow maps or missing lighting. Link's face and body also go very dark in some spots.

For AMD, #1507 fixes the dark lighting and glowing bloom I saw on an RX 5500M: 64-lane graphics warps, and Lichii #273's fragment shuffle fallback. It still needs a tester on RDNA2 or newer.

A clarification for the AMD workaround reported above (RX_VK_TAAU_KEYS=- plus RX_VK_MMA_SOFTWARE=1), from reading the v2.0.12 code and a RX 7800 XT log; I have not tested the dark rooms myself (no Fire Temple on this save).

On a card whose log says matrix multiplies in software (the cooperative matrices lack 16x8x16 f16), the TAAU network is replaced by the stand-in by default: taau_key (vk_draw.cpp ~6254) uses fd029a317a9a4b94 when mma_software is on, and - otherwise.
RX_VK_MMA_SOFTWARE=1 (vk_coopmat.cpp ~581-586) only forces that same software path, so on such a card it should change nothing. The part that matters is RX_VK_TAAU_KEYS=-, which makes the real network run in software; on AMD it costs GPU time (issue AMD RX 9070 XT: OoT's networks fall back to software matrices (no 16x8x16 cooperative matrix), ~56 ms GPU per frame #52: most of a frame on a RX 9070 XT). On the RX 7800 XT I measured about +1.3 ms of 10.6 on an older build.
That fits dark rooms coming from the stand-in's simpler picture and not from the matrices, but that is a reading of the code, not a test; if someone can compare - with RX_VK_MMA_SOFTWARE=1 alone in the same room, it would show which switch does the work.

@lucasmazzoni45-del

A clarification for the AMD workaround reported above (RX_VK_TAAU_KEYS=- plus RX_VK_MMA_SOFTWARE=1), from reading the v2.0.12 code and a RX 7800 XT log; I have not tested the dark rooms myself (no Fire Temple on this save).

On a card whose log says matrix multiplies in software (the cooperative matrices lack 16x8x16 f16), the TAAU network is replaced by the stand-in by default: taau_key (vk_draw.cpp ~6254) uses fd029a317a9a4b94 when mma_software is on, and - otherwise.

RX_VK_MMA_SOFTWARE=1 (vk_coopmat.cpp ~581-586) only forces that same software path, so on such a card it should change nothing. The part that matters is RX_VK_TAAU_KEYS=-, which makes the real network run in software; on AMD it costs GPU time (issue AMD RX 9070 XT: OoT's networks fall back to software matrices (no 16x8x16 cooperative matrix), ~56 ms GPU per frame #52: most of a frame on a RX 9070 XT). On the RX 7800 XT I measured about +1.3 ms of 10.6 on an older build.

That fits dark rooms coming from the stand-in's simpler picture and not from the matrices, but that is a reading of the code, not a test; if someone can compare - with RX_VK_MMA_SOFTWARE=1 alone in the same room, it would show which switch does the work.

Update: Fire Temple dark rooms are fixed on v2.0.13 with no workaround (RX 6700 XT)

Retested the same two rooms from my earlier comment (the caged Goron room and the big lava room with the bridges) on v2.0.13, with no RX_VK_ lighting settings: no RX_VK_TAAU_KEYS, no RX_VK_MMA_SOFTWARE.

Version: v2.0.13 (official HookshotBuilder build), first log line hookshot v2.0.13 (source 54e42459)
GPU: AMD Radeon RX 6700 XT, Windows driver 32.0.21043.1005 (Vulkan driver 0x800161)
CPU / RAM: Ryzen 9 5900X, 32 GB
OS: Windows 11 Home (build 26200)
Overlays / injectors: none

Result: both rooms are lit normally now. Link, the walls, the doorway and the chest are all readable, where on v2.0.11 the same rooms were close to black without the workaround. About 57 FPS, GPU time about 7.8 ms a frame.

From the log, in case it helps: the card still uses software matrices by default (matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)), and on v2.0.13 a second network, 9dc98871eb7fc101, runs alongside fd029a317a9a4b94. On v2.0.11 only fd029a317a9a4b94 appeared.

Correction to my earlier comment: the colour banding I mentioned (flat steps instead of smooth gradients on the lava room's ceiling and walls) is still there on v2.0.13 without the workaround, so it isn't caused by the workaround.

@lucasmazzoni45-del: since the rooms already look right with no settings on v2.0.13, I haven't done that test. I can still run RX_VK_TAAU_KEYS=- alone and RX_VK_MMA_SOFTWARE=1 alone in the same rooms if it would still be useful.

hookshot_v2013_20261110_131010.txt

@Leontfk

Linux / RADV, RDNA2, v2.0.13: interiors crushed to near-black, with only a small lit pool around Link and Navi (screenshot attached)

Adding a data point to this tracker. This is the "crushed / black shadows" family, but on Linux with RADV, which I do not see among the AMD dark-room reports here (the ones I can compare with are on AMD's Windows driver).

What the screenshot shows. An interior with a wooden floor and a rug. A small area around Link's feet and around Navi's glow is lit with normal warm colour; everything more than a short distance away (crates, walls, furniture) is flat grey-blue / near-black, with almost no colour and no visible light falloff. The geometry is all present — this is not a missing-object report (#1002) — it simply receives no ambient or fill light. The presentation looks like the "before" images in @Leontfk's Fire Temple comment in this thread ("most of the room is close to black. Only Navi's glow and a few edges are visible; Link and the walls around him are almost unlit"), though my room is less completely black than those.

Scope (important): this is not a whole-pipeline lighting failure on my card. In a second screenshot taken minutes later outdoors at the ranch in daylight (screenshot-7-ranch-surface.jpg, which I am reporting in #1002 instead), the sky, grass, the horse's shading, its cast shadow and the house are all normally lit and exposed. So the crushed-dark presentation seems specific to certain interiors. That outdoor screenshot has a different problem — flat, near-untextured surfaces (the white stone arch, the house walls) — which belongs to #1002, not here. I mention it so this report is not read as "all lighting is broken on RADV".

Where / how often: I did not write down the in-game room name for this screenshot, so I cannot name it yet; I can supply it on the next run. I have not A/B'd the same room across restarts, so I cannot say whether it is deterministic.

Hookshot version: v2.0.13 (source cfc565a2), Linux native build
Game dump: program 0400486024DEC000 v131072, 25,622,267,860 bytes (23.86 GiB); official nx2/nup.py --verify: verified 372587 records, 161114 unique extents: 0 bad

Full system environment


OS	Arch Linux x86_64 (rolling), kernel `7.2.14-arch1-1`, glibc 2.44
CPU	Intel Core i5-12400F, 12 logical CPUs
RAM	16 GiB (15.47 GiB usable) + 16 GiB zram swap
Compositor	niri `26.04-1` (Wayland), plasmalogin greeter; SDL3 `3.4.18-1`, Wayland `1.26.0-1`
GPU	PowerColor Radeon RX 6750 GRE 10GB, Navi 22 / RDNA2, PCI `1002:73ff`, subsystem `148c:2429`, VBIOS `113-001-X01`, 10224 MiB Hynix VRAM (sysfs `mem_info_vram_total` = `10720641024` bytes)
Driver	Mesa / RADV `1:26.2.6-1` (`mesa`, `vulkan-radeon`, `lib32-mesa`), Vulkan loader `1.4.363.0-1`, `linux-firmware 20261019-1`; the only ICD is `radeon_icd.json` (no AMDVLK)
Vulkan device	`AMD Radeon RX 6750 GRE 10GB (RADV NAVI22)`, Vulkan 1.4, `driver 0x6802006` = `VK_MAKE_VERSION(26,2,6)`
Display	2 x 1920x1080, DP-2 @ 75 Hz (primary) and HDMI-A-1 @ 60 Hz, both SDR
Implicit Vulkan layers installed	`VkLayer_LS_frame_generation.json` (`lsfg-vk-bin 1.0.0-4`), MangoHud `0.8.4-1`, gamescope WSI `3.17.0-1`, MESA anti-lag, MESA device_select

lspci and the kernel misidentify this card as "Navi 23 / Radeon RX 6600" because AMD reused the 0x73ff device ID for the China-only RX 6750 GRE 10GB and pci.ids lacks the 148c:2429 subsystem; RADV reports NAVI22 correctly.

hdr=0 in the options and the log says vi: QueryDisplayHdrStatus -> SDR, so this is not the HDR colour-conversion problem of #1613.

Settings in effect (as text, per the contributing rules — the .ini and env files themselves are not attached):

output_res=1920x1080, render resolution=100%, handheld profile off,
sharpness=70%, frame generation=3x, frame pacing on, frame rate cap=60,
HDR off, upscaler=game's own, fullscreen off.
hookshot_env.txt lines in effect:
  RX_VK_NO_FOLLOW=1
  RX_VK_VRAM_MB=5120
  RX_VK_MIRROR_MB=1024
  RX_VK_NO_MESH=1
  RX_VK_PRECOMPILE=0

No lighting-related RX_VK_ line is set: in particular no RX_VK_TAAU_KEYS and no RX_VK_MMA_SOFTWARE. The NO_MESH / PRECOMPILE=0 / NO_FOLLOW lines are a workaround from v2.0.12 for a pipeline-compilation hang on this driver; I have not A/B'd removing them for this lighting symptom. An external frame-generation implicit layer (lsfg-vk-bin) is installed but I have not confirmed whether it is active for the game process. No ReShade or other injectors.

Log evidence

The attached hookshot_log.txt contains:

[hos host] vk: matrix multiplies in software (no cooperative matrices)
[hos Presentation Thread] vk: program e409733c45530d75 not translated: a network left out on this card
[hos Presentation Thread] vk: program 8306877b7dc8784b not translated: a network left out on this card
... (10 more programs with the same "a network left out on this card" line)

Honest caveat about the log: the attached log is from an earlier ~20-minute run (00:39-00:58 UTC+8) on the same version, GPU and driver, before I changed the render resolution, texture budget and frame generation. This screenshot is from a later run whose output went to the terminal, so it has no matching log yet. I am not claiming those lines were recorded at the exact frame in the screenshot. I will capture the next run with ./bin/hookshot 2>&1 | tee hookshot_log-current.txt and add it here.

Why I am posting here rather than in #1002 or a new issue

#1002 collects invisible/missing objects, which is a different symptom (I have a separate report there with six screenshots). This tracker asks for "screenshot, place, GPU, version, and hookshot_log.txt"; all are provided above or explicitly noted as pending.

Two things may make this a useful data point:

@Leontfk reports the Fire Temple dark rooms are fixed on v2.0.13 with no workaround on an RX 6700 XT (Windows). I still see crushed-to-black interiors on v2.0.13 on Linux/RADV, so the fix may be platform-specific or incomplete.
PR fix(vk): dark lighting and glowing bloom on AMD: 64-lane graphics warps and Lichii #273's fragment shuffle fallback #1507 ("dark lighting and glowing bloom on AMD: 64-lane graphics warps and Lichii AMD RX6600 , I5-11400f , 16gb ram Crash after intro #273's fragment shuffle fallback", including "a basket in Link's house") was merged at 2026-11-10 16:45 UTC, after v2.0.13 (12:59 UTC) and v2.0.14 (16:11 UTC) were published. Consistently, my v2.0.13 hookshot_vk.so contains RX_VK_TAAU_KEYS, RX_VK_MMA_SOFTWARE and RX_VK_NETWORK_KEEP, but not RX_VK_WARP64 or RX_VK_FRAG_SHUFFLE_FALLBACK. The PR title says "on AMD's Windows driver", so my question is: does that 64-lane / fragment-shuffle fix apply to RADV as well? I am on RDNA2 (Navi 22), which the PR says still needs testers for.

Hypothesis only, not a diagnosis: for these interiors only, the software-matrix / network path in #52 and #1006 (the cooperative-matrix probe rejects RDNA, so image networks are stood in or left out) may leave the scene without its ambient/fill composite, leaving only the nearby dynamic lights. Daylight exteriors on the same card look normally lit (see the Scope note above), so I am not claiming a global lighting failure. I have not A/B'd this and am not claiming a causal mechanism. I also have not yet tried the workaround in the issue body (RX_VK_TAAU_KEYS=- + RX_VK_MMA_SOFTWARE=1); both strings exist in my build.

Happy to do any of these next, whichever is most useful: attach a log from the exact same run, A/B RX_VK_TAAU_KEYS=- alone and RX_VK_MMA_SOFTWARE=1 alone in the same room, or test a build with #1507 on RADV.

Attachments

File	Shows
`screenshot-6-dark-room.jpg`	the interior described above: only the area near Link and Navi is lit
`hookshot_log.txt`	earlier run, same v2.0.13 / GPU / driver; contains the software-matrix and network lines quoted above

hookshot_log.txt: hookshot_log.txt

Note: these files are served as static mirrors from a host I control, because the upload path available to me cannot create native GitHub attachments. I can re-upload them as native user-attachments if the tracker prefers.

More reports of this, collected here:

Hyrule Field lighting switches between the dawn/day lighting and a dark night lighting for seconds at a time (reproducible, RTX 5080) #1011: Hyrule Field lighting switches between the dawn/day lighting and a dark night lighting for seconds at a time ( (Source build of main 32df58e (v2.0.5-32) with Lowering: a renamed register's marker avoids every high number the instruction names (glowing flowers and stems) #922, Compute programs prepared before the game find their storage buffer table #761 and NVIDIA DLSS in place of the game's upscale (optional, RTX GPUs) #850 merg; NVIDIA RTX 5080, driver 621.14; Intel i9-13900K, 32 GB DDR5, Windows 11 Pro)
Blocky light halos and checkerboard smoke go away when the few NEAREST samplers are made linear #1117: Blocky light halos and checkerboard smoke go away when the few NEAREST samplers are made linear (v2.0.7; RTX 5080 16 GB, NVIDIA 621.14; Ryzen 9 9900X3D, 64 GB, Windows 11 Pro) (pull request feat(vk): an opt-in linear filter switch to narrow down the blocky light halos (#1117) #1366)
Too much lighting + few seconds freeze during cinematics + sound off while Ganondorf #1555: Too much lighting + few seconds freeze during cinematics + sound off while Ganondorf (v2.0.8; 9700XT 16GB, 26.10.1 (32.0.32015.7029); R7 5800X 32Gb 36000Mhz Windows 10)
Lighting glitch #2148: Lighting glitch (v2.1.0; RTX 2070. Driver 621.4; Ryzen 5 5500, 16 gb, Windows 11)
Version 2.1.0 has an issue where the grass glows. #2153: Version 2.1.0 has an issue where the grass glows. (v2.1.0; RTX5090 621.14; ryzen 7 9800x3d 48GDDR5 win10)
Banding on Skybox #2272: Banding on Skybox (v.2.1.0; RTX 4090, 621.14; Ryzen 7950x, 32GB DDR5 6000, Windows 11)

Tracker upkeep note (merged pull requests and code checked against main 51da0464; no new test run was made for it).

The tracker can mark #1485's filtered depth comparisons, #1507/#1657's subgroup/shuffle repairs, #1338/#2327's specific BC-target repairs and #2289's preserved early sampler/texture registrations as landed. These are distinct lighting mechanisms, and their code is present on main 51da0464. RADV shuffle behavior and compressed 2D attachments still have the separate #1893 and #2001 work, while the remaining volumetric pulse is not diagnosed by those changes. Please keep the tracker open and ask for a current log from the same run as each remaining picture. The earlier Fire Temple confirmation predates #1507's merge and should not be attributed to it.

I just discovered that when I force Mesh Shaders to Compute, it seems to fix all of these issues (I was personally experiencing pixelated halos around particle effects and crushed colors in blurred menu backgrounds). Tested on RTX 4080 SUPER. Hopefully this helps.

Navigation Menu

Repository navigation

[Tracking] Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces #1004

Summary

Affected GPUs and versions

Evidence from the logs

Workarounds

Reports merged here (17 issues, about 28 people)

Adding a report

All tracking issues

11 remaining items

Linux / RADV, RDNA2, v2.0.13: interiors crushed to near-black, with only a small lit pool around Link and Navi (screenshot attached)

Full system environment

Log evidence

Why I am posting here rather than in #1002 or a new issue

Attachments

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Tracking] Lighting: overexposure, over-bright bloom, crushed or black shadows, black faces #1004

Description

Summary

Affected GPUs and versions

Evidence from the logs

Workarounds

Reports merged here (17 issues, about 28 people)

Adding a report

All tracking issues

Activity

HQU-HDR commented on Nov 9, 2026

11 remaining items

J4y0211 commented on Nov 10, 2026

The128ReBits commented on Nov 10, 2026

rakefire-impala commented on Nov 10, 2026

lucasmazzoni45-del commented on Nov 10, 2026

Leontfk commented on Nov 10, 2026

markgeen commented on Nov 10, 2026

Linux / RADV, RDNA2, v2.0.13: interiors crushed to near-black, with only a small lit pool around Link and Navi (screenshot attached)

Full system environment

Log evidence

Why I am posting here rather than in #1002 or a new issue

Attachments

NotRexed commented on Nov 11, 2026

mooki000 commented on Nov 12, 2026

Fry98 commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions