This commit makes operator[] on Vector const and adds a write proxy to it. From
now on writes to Vectors need to happen through the .write proxy. So for
instance:
Vector<int> vec;
vec.push_back(10);
std::cout << vec[0] << std::endl;
vec.write[0] = 20;
Failing to use the .write proxy will cause a compilation error.
In addition COWable datatypes can now embed a CowData pointer to their data.
This means that String, CharString, and VMap no longer use or derive from
Vector.
_ALWAYS_INLINE_ and _FORCE_INLINE_ are now equivalent for debug and non-debug
builds. This is a lot faster for Vector in the editor and while running tests.
The reason why this difference used to exist is because force-inlined methods
used to give a bad debugging experience. After extensive testing with modern
compilers this is no longer the case.
Fixes reported logically dead codes by Coverity
* image.cpp: Doesn't really need any modification. But to remove the bug
report then we have to move the MAX call away from the for loop
statement.
* rasterizer_gles3.cpp: Removes unnecessary elif condition since it is
checked earlier in the function
* collada.cpp: If stamement never reached due to macro ERR_CONTINUE does
the same.
* navigation_mesh.cpp: Variables should always be null - however, also
checked for the very same condition in their function call. Leaving this
for review (whether the function call is necessary or not)
* path_editor_plugin.cpp: If cancel is true, then it should restore the
edited value to the original provided.
http://docs.godotengine.org/en/3.0/classes/class_editorspatialgizmo.html#class-editorspatialgizmo-commit-handle
* spatial_editor_gizmos.cpp: the very condition of i >= 3 is
predetermined in the if case right before it. Thus case 1 is always '1'
and case 2 is always '-1'
* grid_map_editor.cpp: Same as above in spatial_editor_gizmos.cpp
* voxel_light_baker.cpp: Same as above in spatial_editor_gizmos.cpp
* visual_server.cpp: Same as above in spatial_editor_gizmos.cpp
* visual_script_expression.cpp: char '-' is already true in the switch
case mechanism. Thus it can never reach to default case.
* particles.cpp: Case 'PARAM_MAX' is unreachable due to index checking
right before the switch execution.
* shader_language.cpp: Invalid index is handled in switch default case.
`type < TYPE_FLOAT && type > TYPE_VEC4` -> `(type < TYPE_FLOAT || type > TYPE_VEC4`)
Fixes the "always false problem" in TODO comment.
The previous commit corrected the RNG behavior for the lightbaker but
also made it significantly slower on high core count systems. Due to the
vector of states being physically close together in RAM we force a cache
synchronization across all cores whenever we call for the next random
number to be generated.
This will create a temporary local copy of the RNG state before entering
the loop and then saving it back to the global state when done. This
will preserve the per-thread RNG state (and random number quality) while
significantly improving performance.
On my 16 thread box it saves 3 minutes baking the Sponza scene, bringing
performance back in line to before the various RNG fixes were
introduced, being slightly faster than the first implementation.
In our previous attempts to fix the lightmapper we may have
inadvertently introduced the same issue we were trying to fix. It
appears that rand() will on some platforms introduce a mutex making it
slower and on others may have a per-thread state that would need to be
initialized with srand() on each thread. This slows down the lightbaking
further.
This sets up a separate rng state for each OpenMP thread by calling
rand() only in the single-threaded part of the code. We then keep a
vector of states.
I believe this solves our problems.
Based off of perf-based prediction misses these seem to be the
lowest-hanging fruit for quick (albeit small) improvements. These are
based on:
* baking a complex lightmap
* running platformer 3d
* running goltorus
On higher threadcount systems this allows for better utilization. On my
16 thread box CPU use goes from 10 - 11 threads to a steady 15 threads
on the Sponza scene.
Baking time goes from ~10:00 to ~07:30 for me. On lower threadcount
systems I expect some improvement also but likely a little less.
This speeds up the lightmapper by about 10% with no visible impact. A
comparison is up here:
https://tmm.cx/nextcloud/s/Log1eAXen1dJzBz
AMD Ryzen 7 1700 Eight-Core Processor
Sponza scene
pcg32
256/256/high 00:10:13
256/256/medium 00:02:50
256/256/low 00:01:11
xorshift
256/256/high 00:09:32
256/256/medium 00:02:34
256/256/low 00:01:05
-Fixes to unwrapper (remove degenerates), makes Thekla not crash
-Added optional cancel button in EditorProgress
-Added function to force processing of events (needed for cancel button)
Hein-Pieter van Braam
Rémi Verschelde
Michael Alexsander Silva Dias
Crazy-P
Juan Linietsky
Juan Linietsky
Michele Valente