yuzu-emu
/
yuzu
Archived
1
0
Fork 0
Code
This repository has been archived on 2024-03-23. You can view files and clone it, but cannot push or open issues or pull requests.
yuzu/src/video_core/video_core.h

28 lines
486 B
C++
Raw Normal View History

chore: make yuzu REUSE compliant [REUSE] is a specification that aims at making file copyright information consistent, so that it can be both human and machine readable. It basically requires that all files have a header containing copyright and licensing information. When this isn't possible, like when dealing with binary assets, generated files or embedded third-party dependencies, it is permitted to insert copyright information in the `.reuse/dep5` file. Oh, and it also requires that all the licenses used in the project are present in the `LICENSES` folder, that's why the diff is so huge. This can be done automatically with `reuse download --all`. The `reuse` tool also contains a handy subcommand that analyzes the project and tells whether or not the project is (still) compliant, `reuse lint`. Following REUSE has a few advantages over the current approach: - Copyright information is easy to access for users / downstream - Files like `dist/license.md` do not need to exist anymore, as `.reuse/dep5` is used instead - `reuse lint` makes it easy to ensure that copyright information of files like binary assets / images is always accurate and up to date To add copyright information of files that didn't have it I looked up who committed what and when, for each file. As yuzu contributors do not have to sign a CLA or similar I couldn't assume that copyright ownership was of the "yuzu Emulator Project", so I used the name and/or email of the commit author instead. [REUSE]: https://reuse.software Follow-up to 01cf05bc75b1e47beb08937439f3ed9339e7b254
2022-05-15 00:06:02 +00:00
// SPDX-FileCopyrightText: 2014 Citra Emulator Project
// SPDX-License-Identifier: GPL-2.0-or-later
added video_core project to solution
2014-04-05 20:04:25 +00:00
#pragma once
video_core: Make the renderer global a unique_ptr
2015-12-30 13:52:01 +00:00
#include <memory>
OpenGL renderer
2015-05-19 04:21:33 +00:00
gl_shader_disk_cache: Pass core system as argument and guard against games without title ids
2019-01-15 19:28:42 +00:00
namespace Core {
class System;
}
core: Namespace EmuWindow Gets the class out of the global namespace.
2018-08-12 00:20:19 +00:00
namespace Core::Frontend {
Common: Cleanup emu_window includes.
2015-06-21 13:02:11 +00:00
class EmuWindow;
core: Namespace EmuWindow Gets the class out of the global namespace.
2018-08-12 00:20:19 +00:00
}
added video_core project to solution
2014-04-05 20:04:25 +00:00
video_core/gpu: Create threads separately from initialization Like with CPU emulation, we generally don't want to fire off the threads immediately after the relevant classes are initialized, we want to do this after all necessary data is done loading first. This splits the thread creation into its own interface member function to allow controlling when these threads in particular get created.
2019-04-09 18:02:00 +00:00
namespace Tegra {
class GPU;
}
added video_core project to solution
2014-04-05 20:04:25 +00:00
namespace VideoCore {
video_core: Eliminate the g_renderer global variable We move the initialization of the renderer to the core class, while keeping the creation of it and any other specifics in video_core. This way we can ensure that the renderer is initialized and doesn't give unfettered access to the renderer. This also makes dependencies on types more explicit. For example, the GPU class doesn't need to depend on the existence of a renderer, it only needs to care about whether or not it has a rasterizer, but since it was accessing the global variable, it was also making the renderer a part of its dependency chain. By adjusting the interface, we can get rid of this dependency.
2018-08-03 16:55:58 +00:00
class RendererBase;
renderer: Create rasterizer and cleanup.
2018-03-22 23:46:37 +00:00
video_core/gpu: Create threads separately from initialization Like with CPU emulation, we generally don't want to fire off the threads immediately after the relevant classes are initialized, we want to do this after all necessary data is done loading first. This splits the thread creation into its own interface member function to allow controlling when these threads in particular get created.
2019-04-09 18:02:00 +00:00
/// Creates an emulated GPU instance using the given system context.
Frontend/GPU: Refactor context management Changes the GraphicsContext to be managed by the GPU core. This eliminates the need for the frontends to fool around with tricky MakeCurrent/DoneCurrent calls that are dependent on the settings (such as async gpu option). This also refactors out the need to use QWidget::fromWindowContainer as that caused issues with focus and input handling. Now we use a regular QWidget and just access the native windowHandle() directly. Another change is removing the debug tool setting in FrameMailbox. Instead of trying to block the frontend until a new frame is ready, the core will now take over presentation and draw directly to the window if the renderer detects that its hooked by NSight or RenderDoc Lastly, since it was in the way, I removed ScopeAcquireWindowContext and replaced it with a simple subclass in GraphicsContext that achieves the same result
2020-03-25 02:58:49 +00:00
std::unique_ptr<Tegra::GPU> CreateGPU(Core::Frontend::EmuWindow& emu_window, Core::System& system);
video_core/gpu: Create threads separately from initialization Like with CPU emulation, we generally don't want to fire off the threads immediately after the relevant classes are initialized, we want to do this after all necessary data is done loading first. This splits the thread creation into its own interface member function to allow controlling when these threads in particular get created.
2019-04-09 18:02:00 +00:00
Format: Run the new clang format on everything
2018-01-20 07:48:02 +00:00
} // namespace VideoCore