Stowage/godot
2
0
Fork 0
mirror of https://github.com/godotengine/godot.git synced 2025-10-31 21:51:22 +00:00
Code Issues Projects Releases Packages Wiki Activity
godot/servers/server_wrap_mt_common.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

812 lines
64 KiB
C++
Raw Normal View History

Add missing license headers in our source files (#5255) Also removes a couple wrong Godot headers from third-party source files.
2016-06-18 14:46:12 +02:00
/**************************************************************************/
/* server_wrap_mt_common.h */
/**************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/**************************************************************************/
/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur. */
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/**************************************************************************/
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
Code quality: Fix header guards consistency Adds `header_guards.sh` bash script, used in CI to validate future changes. Can be run locally to fix invalid header guards.
2022-07-23 23:41:51 +02:00
#pragma once
Fix typo in preprocessor symbol
2024-06-19 22:04:29 +02:00
#ifdef DEBUG_ENABLED
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
#define MAIN_THREAD_SYNC_CHECK \
if (unlikely(Thread::is_main_thread() && Engine::get_singleton()->notify_frame_server_synced())) { \
MAIN_THREAD_SYNC_WARN \
}
#else
#define MAIN_THREAD_SYNC_CHECK
#endif
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0R(m_r, m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type() override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNCRIDSPLIT(m_type) \
virtual RID m_type##_create() override { \
RID ret = server_name->m_type##_allocate(); \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type##_initialize, ret); \
} else { \
server_name->m_type##_initialize(ret); \
} \
return ret; \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
//RID now returns directly, ensure thread safety yourself
#define FUNCRID(m_type) \
virtual RID m_type##_create() override { \
return server_name->m_type##_create(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0RC(m_r, m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type() const override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0(m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type() override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0C(m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type() const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0S(m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type() override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC0SC(m_type) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type() const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(); \
} \
}
///////////////////////////////////////////////
#define FUNC1R(m_r, m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC1RC(m_r, m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC1S(m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC1SC(m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC1(m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC1C(m_type, m_arg1) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2R(m_r, m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2RC(m_r, m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2S(m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2SC(m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2(m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC2C(m_type, m_arg1, m_arg2) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3R(m_r, m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3RC(m_r, m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3S(m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3SC(m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3); \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
} \
}
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3(m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC3C(m_type, m_arg1, m_arg2, m_arg3) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC4R(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3, p4); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC4RC(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3, p4); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC4S(m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3, p4); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC4SC(m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3, p4); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC4(m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4); \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3, p4); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC4C(m_type, m_arg1, m_arg2, m_arg3, m_arg4) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4); \
} \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
}
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC5R(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3, p4, p5); \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC5RC(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3, p4, p5); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC5S(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5); \
CommandQueueMT doesn't lock during command execution
2017-10-13 18:13:52 +01:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
server_name->m_type(p1, p2, p3, p4, p5); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC5SC(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC5(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC5C(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
#define FUNC6R(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return ret; \
} else { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.flush_if_pending(); \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
return server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC6RC(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6); \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
return ret; \
} else { \
command_queue.flush_if_pending(); \
return server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
}
#define FUNC6S(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
}
#define FUNC6SC(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC6(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC6C(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
A Whole New World (clang-format edition) I can show you the code Pretty, with proper whitespace Tell me, coder, now when did You last write readable code? I can open your eyes Make you see your bad indent Force you to respect the style The core devs agreed upon A whole new world A new fantastic code format A de facto standard With some sugar Enforced with clang-format A whole new world A dazzling style we all dreamed of And when we read it through It's crystal clear That now we're in a whole new world of code
2017-03-05 16:44:50 +01:00
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC7R(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6, p7); \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
return ret; \
} else { \
command_queue.flush_if_pending(); \
return server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
ability to run 2D physics in a thread also, 2D physics is now thread safe too. see physics_2d/thread_model
2015-05-26 01:05:08 -03:00
}
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
#define FUNC7RC(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6, p7); \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
return ret; \
} else { \
command_queue.flush_if_pending(); \
return server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
}
#define FUNC7S(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
}
#define FUNC7SC(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
}
#define FUNC7(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
}
#define FUNC7C(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7); \
} \
}
#define FUNC8R(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6, p7, p8); \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
return ret; \
} else { \
command_queue.flush_if_pending(); \
return server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC8RC(m_r, m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual m_r m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_RET) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
m_r ret; \
Refactor CommandQueueMT to use vararg templates In order to make CommandQueueMT more maintainable this PR changes the previous macro hell with variadic templates instead. This makes the class far more explicit and will allow us to more easily change the way the class functions in the future. Furthermore this refactoring has allowed for some optimizations. In particular by using std::forward to delay the decision of decaying the type to as late as possible we are able to move the data from the callsite into our Command buffer and later move it to the call. In practice what this means is that compared to the old version instead of copying values 3 times, we can now get away with 1 copy, and 1 move for lvalues, and just 2 moves for rvalues. This saves quite a few operations in a hot codepath. We also now test to make sure that the amount of copies and moves are what we expect. This way we can spot performance regressions in this code easily. Somewhat unscientifically, running TPS-demo by pressing enter and not touching the controls average mspf, repeatable across many runs: before: 6.467 after : 6.202
2024-12-23 18:21:39 +01:00
command_queue.push_and_ret(server_name, &ServerName::m_type, &ret, p1, p2, p3, p4, p5, p6, p7, p8); \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
return ret; \
} else { \
command_queue.flush_if_pending(); \
return server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC8S(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC8SC(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH_AND_SYNC) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push_and_sync(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8); \
SYNC_DEBUG \
Use WorkerThreadPool for Server threads * Servers now use WorkerThreadPool for background computation. * This helps keep the number of threads used fixed at all times. * It also ensures everything works on HTML5 with threads. * And makes it easier to support disabling threads for also HTML5. CommandQueueMT now syncs with the servers via the WorkerThreadPool yielding mechanism, which makes its classic main sync semaphore superfluous. Also, some warnings about calls that kill performance when using threaded rendering are removed because there's a mechanism that warns about that in a more general fashion. Co-authored-by: Pedro J. Estébanez <pedrojrulez@gmail.com>
2024-04-04 10:18:08 +02:00
MAIN_THREAD_SYNC_CHECK \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC8(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC8C(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8) const override { \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8); \
} \
}
#define FUNC9(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9); \
} \
}
#define FUNC10(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10); \
} \
}
#define FUNC11(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10, m_arg11) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10, m_arg11 p11) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11); \
} \
}
#define FUNC12(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10, m_arg11, m_arg12) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10, m_arg11 p11, m_arg12 p12) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12); \
} \
}
#define FUNC13(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10, m_arg11, m_arg12, m_arg13) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10, m_arg11 p11, m_arg12 p12, m_arg13 p13) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13); \
} \
}
#define FUNC14(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10, m_arg11, m_arg12, m_arg13, m_arg14) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10, m_arg11 p11, m_arg12 p12, m_arg13 p13, m_arg14 p14) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14); \
} \
}
#define FUNC15(m_type, m_arg1, m_arg2, m_arg3, m_arg4, m_arg5, m_arg6, m_arg7, m_arg8, m_arg9, m_arg10, m_arg11, m_arg12, m_arg13, m_arg14, m_arg15) \
virtual void m_type(m_arg1 p1, m_arg2 p2, m_arg3 p3, m_arg4 p4, m_arg5 p5, m_arg6 p6, m_arg7 p7, m_arg8 p8, m_arg9 p9, m_arg10 p10, m_arg11 p11, m_arg12 p12, m_arg13 p13, m_arg14 p14, m_arg15 p15) override { \
WRITE_ACTION \
Pause physics command queue during physics processing
2025-08-13 22:51:44 +02:00
if (ASYNC_COND_PUSH) { \
Make Servers truly Thread Safe -Rendering server now uses a split RID allocate/initialize internally, this allows generating RIDs immediately but initialization to happen later on the proper thread (as rendering APIs generally requiere to call on the right thread). -RenderingServerWrapMT is no more, multithreading is done in RenderingServerDefault. -Some functions like texture or mesh creation, when renderer supports it, can register and return immediately (so no waiting for server API to flush, and saving staging and command buffer memory). -3D physics server changed to be made multithread friendly. -Added PhysicsServer3DWrapMT to use 3D physics server from multiple threads. -Disablet Bullet (too much effort to make multithread friendly, this needs to be fixed eventually).
2021-02-09 13:19:03 -03:00
command_queue.push(server_name, &ServerName::m_type, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14, p15); \
} else { \
command_queue.flush_if_pending(); \
server_name->m_type(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14, p15); \
} \
A lot of progress with canvas rendering, still far from working.
2019-06-15 23:45:24 -03:00
}
Reference in a new issue Copy permalink