DaemonEngine
Broken rendering on disc surface with Clang 14 and later with `-march=native`
See that vega place in viewpos 486 -57 96 147 24, the wrong black triangles on the disc surface on the right:
The bug disappears with r_deluxeMapping 0:
I'm reproducing it with current master but I was already noticing the problems on commit 9352952a9a04a298c64b7f2360f92e3d5cf3169d. I don't know when the bug was introduced, but the Unvanquished 0.55.2 release build doesn't reproduce the bug.
I use the ultra preset. I'm running it on an AMD Radeon W7600 PRO on Mesa radeonsi 24.2.8 (LLVM 19.1.1).
Also, it may be some other setting really, since disabling deluxe mapping disables a bunch of other features too.
@illwieckz Can you try on OGLP? Also, try with r_showDeluxeMaps 1, r_showNormalMaps 1, and r_showMaterialMaps 1 (separately) to see if any of those appear broken.
Maybe a driver bug?
Maybe, but the release build isn't affected. I may do a bisect at some point.
I don't think anything really changed there except making texture matrices 3x2.
The texture matrix there is just an identity matrix, so it shouldn't be that. These triangles are also all part of the same surface. I wonder if this some different build of the map? Otherwise this bug would probably show up on other maps as well.
I first seen that on a custom built map with custom engine branch, but then I reverted to stock released map and master engine branch to reproduce the bug before reporting it.
I first noticed it on some Xonotic maps with similar geometry, Vega is just the first Unvanquished stock map I reproduced with, there is no reason other Unvanquished maps featuring the same kind of geometry would not be buggy as well.
I reproduce it with Clang 20 and -march=native on a Zen 2 CPU, the bug is still there with fast math disabled.
Since the release wasn't built that way, that may not be a regression.
A release-like build with Clang 20 (not using -march=native) is not affected.
Oh. Maybe it's some SIMD code breaking for triangle processing when loading the BSP, like the R_TBNtoQtangents()? Or a Clang bug.
I starts breaking with Clang 14:
| compiler | status |
|---|---|
| Clang 20 | ❌️ |
| Clang 19 | ❌️ |
| Clang 18 | ❌️ |
| Clang 17 | ❌️ |
| Clang 16 | ❌️ |
| Clang 15 | ❌️ |
| Clang 14 | ❌️ |
| Clang 13 | ✅️ |
| Clang 12 | ✅️ |
| Clang 11 | ✅️ |
| Clang 10 | ✅️ |
https://github.com/DaemonEngine/Daemon/pull/1451#discussion_r1950673023 seems to suggest that R_TBNtoQtangents() may, indeed, be the issue here.
This area of the floor is acted upon by patch stitching. Does the bug go away with r_stitchCurves 0? If so, it is probably caused by a use-after-free in patch stitching fixed in #1639.
Hmm nope. I can reproduce with Linux + Clang 14 + disabling CPU_GENERIC_ARCHITECTURE + -march=native. Setting r_stitchCurves 0 reduces the number of big gaps from 4 to 2, but otherwise the bug looks the same. Fixing the memory bug doesn't do anything.