Commit Graph

29 Commits

Author SHA1 Message Date
degasus b35fa222f5 VideoCommon: perf querys by async events 2015-02-22 08:41:15 +01:00
degasus ad7264da7d VideoCommon: implement swap requests in the full async way 2015-02-22 08:41:15 +01:00
degasus bc248f8941 VideoCommon: use a new async event system for efb access 2015-02-22 08:41:15 +01:00
Fiora 3effd08843 FIFO: allocate slightly more for SIMD vertex loader overreads
May fix crashes in rare cases.
2014-12-10 05:52:55 -08:00
degasus 21970c4a2a VideoCommon: cleanup OpcodeDecoder 2014-12-09 18:56:27 +01:00
degasus 4b22885ed8 VideoCommon: fifo cleanups 2014-12-09 18:56:27 +01:00
Ryan Houdek d58bba2160 Idle loop in GPU loop on dual core systems.
Previously we had decided to busy loop on systems due to Windows' scheduler being terrible and moving us around CPU cores when we yielded.
Along with context switching being a hot spot.
We had decided to busy loop in these situations instead, which allows us greater CPU performance on the video thread.
This can be attributed to multiple things, CPU not downclocking while busy looping, context switches happening less often, yielding taking more time
than a busy loop, etc.

One thing we had considered when moving over to a busy loop is the issues that dual core systems would now face due to Dolphin eating all of their CPU
resources. Effectively we are starving a dual core system of any time to do anything else due to the CPU thread always being pinned at 100% and then
the GPU thread also always at 100% just spinning around. We noted the potential for a performance regression, but dismissed it as most computers are
now becoming quad core or higher.

This change in particular has performance advantages on the dual core Nvidia Denver due to its architecture being nonstandard. If both CPU cores are
maxed out, the CPU can't effectively take any idle time to recompile host code blocks to its native VLIW architecture.
It can still do so, but it does less frequently which results in performance issues in Dolphin due to most code just running through the in-order
instruction decoder instead of the native VLIW architecture.
In one particular example, yielding moves the performance from 35-40FPS to 50-55FPS. So it is far more noticeable on Denver than any other system.
Of course once a triple or quad core Denver system comes out this will no longer be an issue on this architecture since it'll have a free core to do
all of this work.
2014-12-07 05:36:44 +00:00
degasus 90613a1bda OpcodeDecoder: Skip recursiv display lists 2014-11-15 16:24:06 +01:00
degasus cd9f0c34e4 VideoCommon: Remove GetPointer in fifo code 2014-11-01 12:24:43 +01:00
Rohit Nirmal ce8a4f5cc5 VideoCommon: Silence -Wmaybe-uninitialized warnings. 2014-09-30 16:14:18 -04:00
comex 87a95727cd ReadDataFromFifo is always called with len = 32. Remove the parameter to enable optimizations.
And rename some variables around it to be less confusing.
2014-09-29 22:07:16 -04:00
comex 6c0a68d507 Add the override config option.
I hate the config code, but now is not the time to fix it...
2014-09-28 21:34:31 -04:00
comex 3a2048ea57 Add a central variable g_want_determinism which controls whether to try to make things deterministic.
It now affects the GPU determinism mode as well as some miscellaneous
things that were calling IsNetPlayRunning.  Probably incomplete.

Notably, this can change while paused, if the user starts recording a
movie.  The movie code appears to have been missing locking between
setting g_playMode and doing other things, which probably had a small
chance of causing crashes or even desynced movies; fix that with
PauseAndLock.

The next commit will add a hidden config variable to override GPU
determinism mode.
2014-09-28 21:34:31 -04:00
comex 65af90669b Add the 'desynced GPU thread' mode.
It's a relatively big commit (less big with -w), but it's hard to test
any of this separately...

The basic problem is that in netplay or movies, the state of the CPU
must be deterministic, including when the game receives notification
that the GPU has processed FIFO data.  Dual core mode notifies the game
whenever the GPU thread actually gets around to doing the work, so it
isn't deterministic.  Single core mode is because it notifies the game
'instantly' (after processing the data synchronously), but it's too slow
for many systems and games.

My old dc-netplay branch worked as follows: everything worked as normal
except the state of the CP registers was a lie, and the CPU thread only
delivered results when idle detection triggered (waiting for the GPU if
they weren't ready at that point).  Usually, a game is idle iff all the
work for the frame has been done, except for a small amount of work
depending on the GPU result, so neither the CPU or the GPU waiting on
the other affected performance much.  However, it's possible that the
game could be waiting for some earlier interrupt, and any of several
games which, for whatever reason, never went into a detectable idle
(even when I tried to improve the detection) would never receive results
at all.  (The current method should have better compatibility, but it
also has slightly higher overhead and breaks some other things, so I
want to reimplement this, hopefully with less impact on the code, in the
future.)

With this commit, the basic idea is that the CPU thread acts as if the
work has been done instantly, like single core mode, but actually hands
it off asynchronously to the GPU thread (after backing up some data that
the game might change in memory before it's actually done).  Since the
work isn't done, any feedback from the GPU to the CPU, such as real
XFB/EFB copies (virtual are OK), EFB pokes, performance queries, etc. is
broken; but most games work with these options disabled, and there is no
need to try to detect what the CPU thread is doing.

Technically: when the flag g_use_deterministic_gpu_thread (currently
stuck on) is on, the CPU thread calls RunGpu like in single core mode.
This function synchronously copies the data from the FIFO to the
internal video buffer and updates the CP registers, interrupts, etc.
However, instead of the regular ReadDataFromFifo followed by running the
opcode decoder, it runs ReadDataFromFifoOnCPU ->
OpcodeDecoder_Preprocess, which relatively quickly scans through the
FIFO data, detects SetFinish calls etc., which are immediately fired,
and saves certain associated data from memory (e.g. display lists) in
AuxBuffers (a parallel stream to the main FIFO, which is a bit slow at
the moment), before handing the data off to the GPU thread to actually
render.  That makes up the bulk of this commit.

In various circumstances, including the aforementioned EFB pokes and
performance queries as well as swap requests (i.e. the end of a frame -
we don't want the CPU potentially pumping out frames too quickly and the
GPU falling behind*), SyncGPU is called to wait for actual completion.

The overhead mainly comes from OpcodeDecoder_Preprocess (which is,
again, synchronous), as well as the actual copying.

Currently, display lists and such are escrowed from main memory even
though they usually won't change over the course of a frame, and
textures are not even though they might, resulting in a small chance of
graphical glitches.  When the texture locking (i.e. fault on write) code
lands, I can make this all correct and maybe a little faster.

* This suggests an alternate determinism method of just delaying results
until a short time before the end of each frame.  For all I know this
might mostly work - I haven't tried it - but if any significant work
hinges on the competion of render to texture etc., the frame will be
missed.
2014-09-28 21:34:29 -04:00
comex 2d4b7c5900 Make ReadDataFromFifo static. 2014-09-28 21:25:12 -04:00
comex 0ae9e398c8 Rejigger some FIFO buffer variables to be more rational.
videoBuffer -> s_video_buffer
size -> s_video_buffer_write_ptr
g_pVideoData -> g_video_buffer_read_ptr (impl moved to Fifo.cpp)

This eradicates the wonderful use of 'size' as a global name, and makes
it clear that s_video_buffer_write_ptr and g_video_buffer_read_ptr are
the two ends of the FIFO buffer s_video_buffer.

Oh, and remove a useless namespace {}.
2014-09-28 21:25:12 -04:00
Rachel Bryk f93aa7087c Kill Core::g_CoreStartupParameter. 2014-09-09 00:24:49 -04:00
skidau 73fc45db68 Merge pull request #967 from skidau/SyncGPU-SaveState
Added the EmuRunningState check to the GPU thread's FIFO loop
2014-09-05 11:24:46 +10:00
degasus 8b84ddce9a VideoCommon: rewrite frame skipping code 2014-09-04 18:07:39 +02:00
skidau 86db0bf8c3 Added the EmuRunningState check to the GPU thread's FIFO loop so that the GPU thread services any waiting save states. This is needed for games that have the Sync GPU option enabled. 2014-09-04 22:02:21 +10:00
comex 608f9bcd67 Refactor opcode decoding a bit to kill FifoCommandRunnable.
Separated out from my gpu-determinism branch by request.  It's not a big
commit; I just like to write long commit messages.

The main reason to kill it is hopefully a slight performance improvement
from avoiding the double switch (especially in single core mode);
however, this also improves cycle calculation, as described below.

- FifoCommandRunnable is removed; in its stead, Decode returns the
number of cycles (which only matters for "sync" GPU mode), or 0 if there
was not enough data, and is also responsible for unknown opcode alerts.

Decode and DecodeSemiNop are almost identical, so the latter is replaced
with a skipped_frame parameter to Decode.  Doesn't mean we can't improve
skipped_frame mode to do less work; if, at such a point, branching on it
has too much overhead (it certainly won't now), it can always be changed
to a template parameter.

- FifoCommandRunnable used a fixed, large cycle count for display lists,
regardless of the contents.  Presumably the actual hardware's processing
time is mostly the processing time of whatever commands are in the list,
and with this change InterpretDisplayList can just return the list's
cycle count to be added to the total.  (Since the calculation for this
is part of Decode, it didn't seem easy to split this change up.)

To facilitate this, Decode also gains an explicit 'end' parameter in
lieu of FifoCommandRunnable's call to GetVideoBufferEndPtr, which can
point to there or to the end of a display list (or elsewhere in
gpu-determinism, but that's another story).  Also, as a small
optimization, InterpretDisplayList now calls OpcodeDecoder_Run rather
than having its own Decode loop, to allow Decode to be inlined (haven't
checked whether this actually happens though).

skipped_frame mode still does not traverse display lists and uses the
old fake value of 45 cycles.  degasus has suggested that this hack is
not essential for performance and can be removed, but I want to separate
any potential performance impact of that from this commit.
2014-09-01 14:35:23 -04:00
comex 14125cf951 Refactor SetCpStatus into two functions for from-GPU and from-CPU mode rather than a boolean parameter.
This shouldn't affect functionality.  I'm not sure if the breakpoint
distinction is actually necessary (my commit messages from the old
dc-netplay last year claim that breakpoints are broken anyway, but I
don't remember why), but I don't actually need to change this part of
the code (yet), so I'll stick with the trimmings change for now.
2014-08-26 12:43:39 -04:00
degasus 81ed17be53 avoid the extern keyword in .cpp files 2014-07-11 16:10:20 +02:00
Matthew Parlane 31cfc73a09 Fixes spacing for "for", "while", "switch" and "if"
Also moved && and || to ends of lines instead of start.
Fixed misc vertical alignments and some { needed newlining.
2014-03-11 00:35:07 +13:00
Tillmann Karras d802d39281 clang-modernize -use-nullptr
and s/\bNULL\b/nullptr/g for *.cpp/h/mm files not compiled on my machine
2014-03-09 21:14:26 +01:00
Tillmann Karras 315a8ba1c0 Various changes suggested by cppcheck
- remove unused variables
- reduce the scope where it makes sense
- correct limits (did you know that strcat()'s last parameter does not
  include the \0 that is always added?)
- set some free()'d pointers to NULL
2014-02-28 12:43:20 +01:00
Pierre Bourdon 83b7bb64aa Make Common/ mostly IWYU clean (and fix errors in rest of the project detected by this change). 2014-02-22 23:37:29 +01:00
Lioncash 2afe215271 Convert all includes to relative paths. 2014-02-18 02:19:10 -05:00
Jasper St. Pierre 34692ab826 Remove unnecessary Src/ folders 2013-12-31 14:03:19 -05:00