Refactored the following template classes by replacing runtime checks with compile-time checks using if constexpr for improved code clarity and maintainability:
- RID_Alloc
- SortArray
- PagedAllocator
Changes made:
- Updated conditional checks for THREAD_SAFE in the RID_Alloc class.
- Updated conditional checks for Validate in the SortArray class.
- Updated conditional checks for thread_safe in the PagedAllocator class.
PR #90993 added several debugging utilities.
Among them, advanced memory tracking through the use of custom
allocators and VK_EXT_device_memory_report.
However as issue #95967 reveals, it is dangerous to leave it on by
default because drivers (or even the Vulkan loader) can too easily
accidentally break custom allocators by allocating memory through std
malloc but then request us to deallocate it (or viceversa).
This PR fixes the following problems:
- Adds --extra-gpu-memory-tracking cmd line argument
- Adds missing enum entries to
RenderingContextDriverVulkan::VkTrackedObjectType
- Adds RenderingDevice::get_driver_and_device_memory_report
- GDScript users can easily check via print(
RenderingServer.get_rendering_device().get_driver_and_device_memory_report()
)
- Uses get_driver_and_device_memory_report on device lost for appending
further info.
Fixes#95967
InputEventMouseMotion may fire when the mouse hasn't moved.
Also, it generally won't fire when the mouse stops moving.
This makes reliably detecting when the mouse isn't moving tricky.
Update the docs for InputEventMouseMotion to capture these caveats
and give guidance for the best way to detect lack of mouse movement.
InputEventMouseMotion isn't guaranteed to fire only on actual mouse
movement. It's not uncommon for the underlying OS motion event to be
sent either by the OS itself or another application even though the
mouse hasn't moved. Godot will generate such zero-motion
InputEventMouseMotion events itself for things like cursor shape
changes.
Once started, the tooltip timer is reset only after a mouse movement of
at least 5 pixels in one frame.
- Implements the concept of GDExtension loaders that can be used to customize how GDExtensions are loaded and initialized.
- Moves the parsing of `.gdextension` config files to the new `GDExtensionLibraryLoader`.
- `GDExtensionManager` is now meant to be the main way to load/unload extensions and can optionally take a `GDExtensionLoader`.
- `EditorFileSystem` avoids unloading extensions if the file still exists, this should prevent unloading extensions that are outside the user project.
Features:
- Debug-only tracking of objects by type. See
get_driver_allocs_by_object_type et al.
- Debug-only Breadcrumb info for debugging GPU crashes and device lost
- Performance report per frame from get_perf_report
- Some VMA calls had to be modified in order to insert the necessary
memory callbacks
Functionality marked as "debug-only" is only available in debug or dev
builds.
Misc fixes:
- Early break optimization in RenderingDevice::uniform_set_create
============================
The work was performed by collaboration of TheForge and Google. I am
merely splitting it up into smaller PRs and cleaning it up.
1. Make handling of user tokens atomic:
Loads started with the external-facing API used to perform a two-step setup of the user token. Between both, the mutex was unlocked without its reference count having been increased. A non-user-initiated load could therefore destroy the load task when it unreferenced the token.
Those stages now happen atomically so in the one hand, the described race condition can't happen so the load task life insurance doesn't have a gap anymore and, on the other hand, the ugliness that the call to load could return `ERR_BUSY` if happening while other thread was between both steps is gone.
The code has been refactored so the user token concerns are still outside the inner load start function, which is agnostic to that for a cleaner implementation.
2. Clear ambiguity between load operations running on `WorkerThreadPool`:
The two cases are: single-loaded thread directly started by a user pool task and a load started by the system as part of a multi-threaded load.
Since ensuring all the code dealing with this distinction would make it very complex, and error-prone, a different measure is applied instead: just take one of the cases out of the dicotomy. We now ensure every load happening on a pool thread has been initiated by the system.
The way of achieving that is that a single-threaded user-started load initiated from a pool thread, is run as another task.
DeeJayLSP
Craig-Stoneham
Adam Scott
A Thousand Ships
Saracen
Matias N. Goldberg
Stuart Carnie
Tallivm
Rémi Verschelde
Joel Winarske
kit
David Giardi
Alex Docauer
Lars Pettersson
Radiant
David Snopek
Rakka Rage
Dungeon Master
bruvzg
Vinni Richburgh
passivestar
Raul Santos
Bastiaan Olij
Goutte
Rémi Verschelde
BlueCube3310
clayjohn
kobewi
Pedro J. Estébanez