ShuriZma
/
dolphin
mirror of https://github.com/dolphin-emu/dolphin.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
dolphin/Source/Core/Core/System.cpp

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

26 lines
457 B
C++
Raw Normal View History

Core: Add initial System class Introduces the system class that will eventually contain all relevant system state, as opposed to everything being distributed all over the place as global variables. Throughout the codebase we have code that from its interface-view, does not actually require its dependencies to be described in the interface, and we routinely run into issues with initialization where we sometimes make use of a facility before it's been initialized, which leads to annoying to debug cases, because the reader needs to run through the codebase and see what order things get initialized in, and how they're being used. This is particularly a frequent issue in the video code. Further, we also have a lot of code that makes use of file-scope variables (many of which are non-trivial), which must all be default initialized before the application can actually enter main(). While this may not be a huge issue in itself, some of these are allocating, which means that the application may need to use memory that it otherwise wouldn't need to (e.g. when a game isn't running, this excess memory is being used). Being able to wrap all these subsystems into objects would be nicer, since they can be constructed when they're actually needed. Them being objects also means we can better express dependencies on subsystems as types directly in the interface, making them explicit to the reader instead of a change randomly blowing up, said reader inspecting it, and finding out that something needed to be initialized beforehand. With the global turned into a function parameter, the dependency is explicit and they know just by reading it, that the given subsystem needs to be in a valid state before calling the function. For a prior example of an emulator that has moved to this model, see yuzu, which has been migrated off of global variables all over the place and replaced with a system instance (which has now reached the stage, where the singleton can be removed).
2020-12-20 03:32:55 +00:00
// Copyright 2020 Dolphin Emulator Project
treewide: convert GPLv2+ license info to SPDX tags SPDX standardizes how source code conveys its copyright and licensing information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX tags are adopted in many large projects, including things like the Linux kernel.
2021-07-05 01:22:19 +00:00
// SPDX-License-Identifier: GPL-2.0-or-later
Core: Add initial System class Introduces the system class that will eventually contain all relevant system state, as opposed to everything being distributed all over the place as global variables. Throughout the codebase we have code that from its interface-view, does not actually require its dependencies to be described in the interface, and we routinely run into issues with initialization where we sometimes make use of a facility before it's been initialized, which leads to annoying to debug cases, because the reader needs to run through the codebase and see what order things get initialized in, and how they're being used. This is particularly a frequent issue in the video code. Further, we also have a lot of code that makes use of file-scope variables (many of which are non-trivial), which must all be default initialized before the application can actually enter main(). While this may not be a huge issue in itself, some of these are allocating, which means that the application may need to use memory that it otherwise wouldn't need to (e.g. when a game isn't running, this excess memory is being used). Being able to wrap all these subsystems into objects would be nicer, since they can be constructed when they're actually needed. Them being objects also means we can better express dependencies on subsystems as types directly in the interface, making them explicit to the reader instead of a change randomly blowing up, said reader inspecting it, and finding out that something needed to be initialized beforehand. With the global turned into a function parameter, the dependency is explicit and they know just by reading it, that the given subsystem needs to be in a valid state before calling the function. For a prior example of an emulator that has moved to this model, see yuzu, which has been migrated off of global variables all over the place and replaced with a system instance (which has now reached the stage, where the singleton can be removed).
2020-12-20 03:32:55 +00:00
#include "Core/System.h"
Config: Port dual core setting to new config system.
2022-01-07 02:50:18 +00:00
#include "Core/Config/MainSettings.h"
Core: Add initial System class Introduces the system class that will eventually contain all relevant system state, as opposed to everything being distributed all over the place as global variables. Throughout the codebase we have code that from its interface-view, does not actually require its dependencies to be described in the interface, and we routinely run into issues with initialization where we sometimes make use of a facility before it's been initialized, which leads to annoying to debug cases, because the reader needs to run through the codebase and see what order things get initialized in, and how they're being used. This is particularly a frequent issue in the video code. Further, we also have a lot of code that makes use of file-scope variables (many of which are non-trivial), which must all be default initialized before the application can actually enter main(). While this may not be a huge issue in itself, some of these are allocating, which means that the application may need to use memory that it otherwise wouldn't need to (e.g. when a game isn't running, this excess memory is being used). Being able to wrap all these subsystems into objects would be nicer, since they can be constructed when they're actually needed. Them being objects also means we can better express dependencies on subsystems as types directly in the interface, making them explicit to the reader instead of a change randomly blowing up, said reader inspecting it, and finding out that something needed to be initialized beforehand. With the global turned into a function parameter, the dependency is explicit and they know just by reading it, that the given subsystem needs to be in a valid state before calling the function. For a prior example of an emulator that has moved to this model, see yuzu, which has been migrated off of global variables all over the place and replaced with a system instance (which has now reached the stage, where the singleton can be removed).
2020-12-20 03:32:55 +00:00
namespace Core
{
struct System::Impl
{
};
System::System() : m_impl{std::make_unique<Impl>()}
{
}
System::~System() = default;
Config: Port dual core setting to new config system.
2022-01-07 02:50:18 +00:00
void System::Initialize()
{
m_separate_cpu_and_gpu_threads = Config::Get(Config::MAIN_CPU_THREAD);
Config: Port MMU setting to new config system.
2022-01-07 03:37:07 +00:00
m_mmu_enabled = Config::Get(Config::MAIN_MMU);
Config: Port dual core setting to new config system.
2022-01-07 02:50:18 +00:00
}
Core: Add initial System class Introduces the system class that will eventually contain all relevant system state, as opposed to everything being distributed all over the place as global variables. Throughout the codebase we have code that from its interface-view, does not actually require its dependencies to be described in the interface, and we routinely run into issues with initialization where we sometimes make use of a facility before it's been initialized, which leads to annoying to debug cases, because the reader needs to run through the codebase and see what order things get initialized in, and how they're being used. This is particularly a frequent issue in the video code. Further, we also have a lot of code that makes use of file-scope variables (many of which are non-trivial), which must all be default initialized before the application can actually enter main(). While this may not be a huge issue in itself, some of these are allocating, which means that the application may need to use memory that it otherwise wouldn't need to (e.g. when a game isn't running, this excess memory is being used). Being able to wrap all these subsystems into objects would be nicer, since they can be constructed when they're actually needed. Them being objects also means we can better express dependencies on subsystems as types directly in the interface, making them explicit to the reader instead of a change randomly blowing up, said reader inspecting it, and finding out that something needed to be initialized beforehand. With the global turned into a function parameter, the dependency is explicit and they know just by reading it, that the given subsystem needs to be in a valid state before calling the function. For a prior example of an emulator that has moved to this model, see yuzu, which has been migrated off of global variables all over the place and replaced with a system instance (which has now reached the stage, where the singleton can be removed).
2020-12-20 03:32:55 +00:00
} // namespace Core