The function update_perf_report() is expensive and is called every
frame.
Most of it is not necessary unless the user calls get_perf_report
Affects #102173
Building with the following params (note: scu_build is enabled):
```
platform=linuxbsd builtin_embree=yes builtin_enet=no
builtin_freetype=yes builtin_graphite=yes builtin_harfbuzz=yes
builtin_libogg=no builtin_libpng=yes builtin_libtheora=no
builtin_libvorbis=no builtin_libwebp=no builtin_miniupnpc=no
builtin_pcre2=no builtin_zlib=yes builtin_zstd=no linker=mold
optimize=none debug_symbols=True tests=True dev_mode=True dev_build=True
use_llvm=yes use_lld=yes opengl3=no openxr=no disable_xr=yes -j 24
scu_build=yes scu_limit=256
```
Results in compiler errors:
```
In file included from servers/register_server_types.cpp:99:
servers/xr/xr_interface.h:52:7: error: redefinition of 'RefCounted'
52 | class XRInterface : public RefCounted {
| ^
./servers/rendering/rendering_method.h:40:21: note: expanded from macro
'XRInterface'
40 | #define XRInterface RefCounted
| ^
./core/object/ref_counted.h:37:7: note: previous definition is here
37 | class RefCounted : public Object {
| ^
```
This happens because of:
```
#ifdef XR_DISABLED
// RendererSceneCull::render_camera is empty when 3D is disabled, but
// it and RenderingMethod::render_camera have a parameter for
XRInterface.
#define XRInterface RefCounted
#else
#include "servers/xr/xr_interface.h"
#endif // XR_DISABLED
```
In rendering_method.h
This batches together a couple of micro-optimizations that were discovered in profiling and analyzing disassembly.
Importantly, this reduces the amount of instructions in a heavy loop. This has the biggest impact when there are lots of objects and lights in the scene as the function is called once per objects + once per light that touches the object
Clustered performs the following shadow rendering steps
1. Process objects [0; 10) for cascade 0.
2. Process objects [10; 30) for cascade 1.
3. Process objects [30; 100) for cascade 2.
4. Upload objects [0; 100) to GPU.
5. Draw all cascades.
Mobile was supposed to be doing the same, but instead was doing:
1. Process objects [0; 10) for cascade 0.
2. Upload objects [0; 10) to GPU.
3. Process objects [10; 30) for cascade 1.
4. Upload objects [0; 30) to GPU.
5. Process objects [30; 100) for cascade 2.
6. Upload objects [0; 100) to GPU.
7. Draw all cascades.
That is, always reuploaded everything from scratch.
Therefore it pointlessly (and with geometric growth) wasted BW.
Revert "Removed translations of unused error message"
This reverts commit 6dbc75e000375196eb0176e65eb41935f71fc4fe.
Variable name change
Detecting multiple default cases in shaders
Removed translations of unused error message
Allowing default case at top of scope in switch statement in shaders
And anything that uses luminance.
The class Luminance in luminance.cpp is in charge of averaging the
luminance of all pixels.
It performs multiple passes until it reaches a 1x1 texture containing
the total average. This is standard luminance averaging on GPU.
Then the "result" of this frame and the "prev_frame_result" are averaged
together at a certain speed to mimic eye adaptation.
Then this avarege becomes the "source" for the next frame. This is done
here:
```cpp
SWAP(p_luminance_buffers->current,
p_luminance_buffers->reduce.write[p_luminance_buffers->reduce.size() -
1]);
```
So far pretty normal stuff.
**The problem is: prev_frame_result IS UNINITIALIZED**. Therefore it's
possible for prev_frame_result to contain garbage values like -5+e15
which causes the screen to stay black for a minute until eye adaptation
catches up.
Windows will always force allocations to be reset to 0, but Linux does
not do that.
However Windows just delays the bug; because it's possible for VMA to
reuse a block.
You can repro this bug by downloading Bistro, creating a camera,
selecting a default scene; and then launching Bistro.
Everything will work fine.
Until you decide to resize the window. It takes a few tries on Godot,
but eventually the screen becomes black.
If you wait around a minute, the screen will "unblack" itself back to
normal.
Even if it's not stuck in black after resize, you may notice that every
resize is inconsistent in how the eye adaptation catches up (i.e.
sometimes it flashes to white, sometimes it does not).
If you can't repro the bug, you need to try harder by doing arbitrary
resizes until it triggers.
Also, I advise to try this on Linux; since Windows' sanitization of
memory gets in the way.
There's probably multiple tickets already filled around issues that were
rooted in luminance calculations starting from uninitialized memory.
This PR sets a default value of 0, which causes the screen to always
flash white after resize. Setting a different value like 0.1 makes the
flash effect weaker. Setting it to a high value like 5.0 makes the
screen flash from dark instead.
This bug can be backported to 4.3. I don't know if it can be backported
to earlier; as the render graph makes sure the texture_clear() calls
gets issued in the right place; whereas in <= 4.2 it might be
problematic depending on when Luminance::LuminanceBuffers::configure is
being called.
Thaddeus Crews
A Thousand Ships
Pāvels Nadtočajevs
Lukas Tenbrink
Matias N. Goldberg
clayjohn
Rémi Verschelde
LuoZhihao
yesfish
Rémi Verschelde
Evan Todd
David Snopek
Michael Alexsander
Murrent
kleonc