* Updated Launching of Lua Editor to supply the project-path
The Lua Launch logic also uses the AzFramework ProcessLauncher instead
of Qt. This has the benefit of being able to pass arguments as an array
instead of in a single string. Therefore paths with spaces in them also
work.
Tweak the Settings Registry logic to locate the
project-path/engine-path by scanning upwards for a
project.json/engine.json respectively to inject the found paths to the
front of the command line parameters instead of the back.
This has the effect of making sure that command line parameters for the
project-path/engine-path always takes precedence over scanning upwards
for a project.json/engine.json.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed prepend of EngineRoot in CheckProjectPathProvided
The Editor would attempt to validate that the project path supplied via
the command line contained a valid project.json file before contining
the Editor startup flow.
This was taking the engine root path and appending the project path to
it, which works when the project path is absolute
But when the project path is relative it is treated as relative to the
current working directory by the SettingsRegistry, but the logic in the
CheckProjectPathProvided was treating it has relative to the engine
root. Therefore supplying a relative path as part of the Editor.exe
launch command would fail.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Fixed resolving of relative paths to absolute paths in the Editor
The Editor was changing the current working directory to the nearest
ancestor directory containing an `engine.json` file.
This resulted in the ConvertToAbsolutePath function resolving relative
paths to that directory instead of the launch directory of the Editor.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
Consolidated the contents of CpuProfilerImp.h into CpuProfiler.h
Renamed CpuProfilerImpl.cpp to CpuProfiler.cpp
Collapsed the CpuProfilerImpl class into the intermediary CpuProfiler interface class, removing that interface type
Replaced all calls to the old CpuProfiler interface with AZ::Debug::ProfilerSystemInterface
Added accessor to see if a continuous capture is in progress to AZ::Debug::ProfilerRequests
Signed-off-by: AMZN-ScottR 24445312+AMZN-ScottR@users.noreply.github.com
GCC doesn't accept accessing member variables inside the noexcept expression of a member function.
GCC also requires that template specializations for an inner template be outside of all classes.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
- Use `unordred_map` (speed is about the same but providing a hash is slightly nicer than operator<)
- Do better arg forwarding where applicable
- Swap EXPECT_ test ordering
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Up the hard coded size for the HpAllocator buffer to 18KiB
Added a static assert in the HphaSchema.cpp file to validate that the
HpAllocator aligned storage buffer is at least the size of the
HpAllocator class.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed comment blocks with username from HphaSchema.h
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
Fixed crash in Allocators Benchmark multithreaded test due to the HPHA schema not having proper multithread protection around the `mFreeTree` member in `tree_get_unused_memory` function.
The `mFreeTree intrusive set is able to modified on multiple threads.
Replaced the custom intrusive_list implementation n HPHA schema with AZStd::intrusive_list
Added a `ScopedAllocatorBenchmarkEnvironment` class to provide an RAI mechanism for initializing the SystemAllocator in Benchmark Test
Rermoved the `AzCoreBenchmarkEnvironment` in lieu of the `ScopedAllocatorBenchmarkEnvironment` class
Fixed assert when running Allocator Benchmarks in debug due to mismatch PauseTiming/ResumeTiming in Allocator Benchmark Fixtures
Added `ScopedRegisterBenchmarkEnvironment` RAII class to provide lifetime guarantees on BenchmarkEnvironments registered via the `AZ_UNIT_TEST_HOOK`
Initialized the intrusive_multiset_node members to nullptr in all build configurations instead of only debug as the cost negligible and it is useful for debugging.
fixes LYN-10210
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added Async APIs for the various Process*FromList terrain functions.
Please note that we are currently defaulting the number of worker threads to one, because splitting the work over multiple threads causes contention when locking various mutexes, resulting in slower overall wall time for async requests split over multiple threads vs one where all the work is done on a single thread. The latter is still preferable over a regular synchronous call because it is just as quick and prevents the main thread from blocking. This should be changed once the mutex contention issues have been addressed, so that async calls automatically split the work between available job manager worker threads, unless the ProcessAsyncParams specify a different desired number of jobs.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Fix Linux builds by adding missing #include
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Added a test for cancellation of terrain async requests, and fix it so that it works.
Note that the benchmarks show this implementation to be slightly slower than the previous one, which I presume is because we're now calling a 'perSurfacePointFunction' in the inner loop; this can probably be addressed, but will result in a lot of code duplication, and I think efforts will be better spent on removing the mutex contention to enable running multiple terrain async jobs at the same time.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Added Async versions for all Process*Region terrain API functions, along with benchmarks.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Fix the newly added terrain async request benchmarks to actually use the async APIs.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Revert to the original version which just calls the synchronous API from the job function, along with some other updates in response to review feedback.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Change the TerrainWorldDebugger to use the async API, along with the following changes:
- TerrainJobContext no longer uses a JobCancelGroup so we can guarantee the completion callbacks of associated jobs will be invoked even if it is cancelled.
- As a result of the above change, the ProcessAsyncCompleteCallback function signature again accepts the associated TerrainJobContext as a param.
- The TerrainProcessAsyncCancellation test has been resurrected and simplified by using binary semaphores instead of condition variables.
- All the async related TerrainSystemBenchmark functions have been simplified by using binary semaphores instead of condition variables.
- Global cancellation of all terrain jobs on deactivation of the TerrainSystem has been reintroduced, but in a different way than before.
- Other miscellaneous changes/fixes made while testing and based on earlier PR feedback.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Updates based on review feedback:
- Go back to using a vector instead of an array (fixed the original problem by adding custom copy/assignment constructors/operators to the WireframeSector struct).
- When calling WireframeSector::Reset, block until any associated in flight has completed.
- Added the concept of a minimum number of positions per terrain job.
Signed-off-by: bosnichd <bosnichd@amazon.com>
* Use semaphore instead of binary_semaphore in a bunch of places to account for the race condition where a completion callback fires before we started waiting for it.
Signed-off-by: bosnichd <bosnichd@amazon.com>
This work has been on hold for a while. Revisiting removal of thumbnail contexts now while debugging related lockups exiting tools from script. Thumbnail contexts are an unused layer of indirection that makes debugging the system more difficult. All systems were only referencing the default context.
Signed-off-by: Guthrie Adams <guthadam@amazon.com>