| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
837133792d queues the GMMU maps on the GPU thread (GPU::RunInOrder) so the
service thread never waits for the texture cache. With the GPU split
(Low GPU accuracy) the GPU thread defers queued functions to its back, but
its front reads the command lists: it read the lists submitted after a map
through GPU addresses that weren't mapped yet. Pokopia stopped after its
first frame.
Add GPU::MapInOrder for the GMMU maps and the sparse tile remaps. It runs
in order like RunInOrder, and with the split it runs on the front after
draining the back, before the front reads further command lists. The
service thread still never takes the texture cache lock, and the back is
idle while the map changes the caches. Unmaps and the other queued work
still run on the back.
Assisted-by: Claude Opus 5.5 (bisect, fix, testing and commit message)
|
| |
|
|
|
|
|
|
|
|
|
| |
NormalUnmapGpuMemory4K and destroying GPU memory are jobs the console's
graphics server completes behind the work already submitted. Run the GMMU
unmaps on the GPU thread after the command lists queued before them
(GPU::RunInOrder) and signal the job's event only then, instead of unmapping
and signalling at once while Eden's GPU thread may still be behind.
Also EDEN_NX2_FRAMES_AHEAD (experimental): wait for the previous frame's
fence at present instead of this one's.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thread may be destroyed at dtor(), but it hasn't fully shut down, so before notify shutdown, request immediate stop (effective immediately).
Like the issue was that the thread didn't want to stop running, thus it would hang, it would also reference objects which were being destroyed without waiting for them to actually be destroyed
So it would reference invalid data
This PR tells the thread: "hey, STOP now, and DESTROY yourself"
So all of that should be avoided
Signed-off-by: lizzie <lizzie@eden-emu.dev>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4395
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
| |
reworked a bit to remove references of parent objects and instead pass as arguments to methods to prevent useless reloads
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Co-authored-by: maufeat <sahyno1996@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3908
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPU threading. (#3579)
(Merge of #3495 + #3108)
This PR works around to simplify math operations on hot pointers inside the access and requests to the cache of buffers and texture cache, removing previous logic of indirection and replaced by a PoD approach.
This will ensure less CPU times spended on the same request and flow directly into another chain of the render, in the same way, command queue currently uses an internal mutex that constraints the flow of data within the GPU threads, we're moving over a single command, I verified to keep using mutexes instead of internal mutex + mutex per operation, which are resolved by themselves.
In simplier words, this aims to improve performance on those games and devices where the waits for next orders on GPU commands were heavier than a single verification.
Co-Authored-by: @CamilleLaVey
Co-Authored-by: @Lizzie
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3579
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Call rasterizer->ReleaseFences() directly
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The bounded MPSCQueue implementation causes crashes in Fire Emblem Three Houses, use the previous implementation for now.
|
| |
|
|
|
|
|
|
| |
While this is the primary change, we also:
- Remove the mpsc namespace and rename Queue to MPSCQueue
- Make Slot a private struct within MPSCQueue
- Remove the AlignedAllocator template argument, as we use std::allocator
- Replace instances of mask + 1 with capacity, and mask + 2 with capacity + 1
|
| | |
|
| |
|
|
|
| |
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
|
| | |
|
| | |
|
| |
|
|
| |
There is no need for a busy loop here. Let's just use a condition variable to save some power.
|
| |
|
|
|
| |
Else the fence might get submited out-of-order into the queue, which makes testing them pointless.
Overhead should be tiny as the mutex is just moved from the queue to the writing code.
|
| |
|
|
|
|
| |
This was implicitly done by `is_powered_on = false`, however the explicit method allows us to block until the GPU is actually gone.
This should fix a race condition while removing the other subsystems while the GPU is still active.
|
| |
|
|
| |
This commit removes early placeholders for an implementation of async nvdec. With recent changes to the source code, the placeholders are no longer accurate, and can cause a nullptr dereference due to the nature of the cdma_pusher lifetime.
|
| |
|
|
|
|
| |
Instead of using a two step initialization to report errors, initialize
the GPU renderer and rasterizer on the constructor and report errors
through std::runtime_error.
|
| | |
|
| |
|
|
| |
- We must always use a GPU thread now, even with synchronous GPU.
|
| |
|
|
|
|
| |
Resolves variable shadowing scenarios up to the end of the OpenGL code
to make it nicer to review. The rest will be resolved in a following
commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit aims to implement the NVDEC (Nvidia Decoder) functionality, with video frame decoding being handled by the FFmpeg library.
The process begins with Ioctl commands being sent to the NVDEC and VIC (Video Image Composer) emulated devices. These allocate the necessary GPU buffers for the frame data, along with providing information on the incoming video data. A Submit command then signals the GPU to process and decode the frame data.
To decode the frame, the respective codec's header must be manually composed from the information provided by NVDEC, then sent with the raw frame data to the ffmpeg library.
Currently, H264 and VP9 are supported, with VP9 having some minor artifacting issues related mainly to the reference frame composition in its uncompressed header.
Async GPU is not properly implemented at the moment.
Co-Authored-By: David <25727384+ogniK5377@users.noreply.github.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
- Necessary for multiple service threads.
|
| | |
|
| |
|
|
|
|
|
| |
This commit uses guest fences on vSync event instead of an articial fake
fence we had.
It also corrects to keep signaling display events while loading the game
as the OS is suppose to send buffers to vSync during that time.
|
| | |
|
| | |
|
| |\
| |
| | |
video_core/gpu_thread: Remove redundant copy constructor for CommandDataContainer
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
CommandDataContainer
std::move within a copy constructor (on a data member that isn't
mutable) will always result in a copy. Because of that, the behavior of
this copy constructor is identical to the one that would be generated
automatically by the compiler, so we can remove it.
|
| |/
|
|
|
| |
With C++17's deduction guides, the type doesn't need to be explicitly
specified within locking primitives anymore.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
Since C++17, the introduction of deduction guides for locking facilities
means that we no longer need to hardcode the mutex type into the locks
themselves, making it easier to switch mutex types, should it ever be
necessary in the future.
|
| |
|
|
|
|
| |
The pusher instance is only ever used in the constructor of the
ThreadManager for creating the thread that the ThreadManager instance
contains. Aside from that, the member is unused, so it can be removed.
|
| | |
|
| |
|
|
|
| |
This function didn't have a definition, so we can remove it to prevent
accidentally attempting to use it.
|
| |
|
|
|
|
|
| |
Moves the data members to satisfy the order they're declared as in the
constructor initializer list.
Silences a -Wreorder warning.
|
| | |
|
| |
|