| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It's only used as an interface between two classes. So no need to declare
it in the backend export header.
|
|
|
|
|
|
|
|
|
|
|
|
Replace 'int' keys with something that carries type information.
Performance is neutral.
|
|
VertexManagerBase: Get rid of static state
|
|
Fifo: Make SyncGPUReason an enum class
|
|
|
|
Common: Namespace MemoryUtil
|
|
|
|
Replaces old and simple usages of std::atomic<bool> with Common::Flag
(which was introduced after the initial usage), so it's clear that
the variable is a flag and because Common::Flag is well tested.
This also replaces the ready logic in WiimoteReal with Common::Event
since it was basically just unnecessarily reimplementing Common::Event.
|
|
|
|
BlockingLoop was being woken when the emulator was being paused
which would cause the loop to busy spin. Issue 9692.
|
|
|
|
Also changed a few functions to be static.
|
|
|
|
This is only ever queried, making it a global isn't necessary.
|
|
Fifo: Fix SyncGPU.
|
|
|
|
CBoot::BootUp() did call CoreTiming::Advance which itself blocks on the GPU,
but the GPU thread wasn't started already. This commit moves the SyncGPU
initialization into the Fifo.cpp file and call it after BootUp().
|
|
|
|
Also remedies places where the video backends and core rely on things
being indirectly included.
|
|
|
|
Also moves it to the cpp file where it's used.
|
|
It may be a bit weird to see calls to static functions in
VertexManagerBase now, but at least it's easier to see what's going on.
|
|
|
|
|
|
The new implementation has 3 options:
SyncGpuMaxDistance
SyncGpuMinDistance
SyncGpuOverclock
The MaxDistance controlls how many CPU cycles the CPU is allowed to be in front
of the GPU. Too low values will slow down extremly, too high values are as
unsynchronized and half of the games will crash.
The -MinDistance (negative) set how many cycles the GPU is allowed to be in
front of the CPU. As we are used to emulate an infinitiv fast GPU, this may be
set to any high (negative) number.
The last parameter is to hack a faster (>1.0) or slower(<1.0) GPU. As we don't
emulate GPU timing very well (eg skip the timings of the pixel stage completely),
an overclock factor of ~0.5 is often much more accurate than 1.0
|
|
This merges two atomic<bool> into one atomic<int>.
We did move the bit from one bool to another, now we can use operator--.
|
|
It's now a new helper function within common.
|
|
Also remove said variables from being globals.
|
|
|
|
|
|
|
|
(GpuRunningState=false)
This was causing a race condition where the "absurdly large aux buffer"
panic alert would be triggered in the last bit of fifo processing on the
CPU thread in deterministic mode (i.e. netplay). SyncGPU is supposed to
move the auxiliary queue data to the beginning of the containing buffer
so we don't have to deal with wraparound; if GpuRunningState is false,
however, it just returns, because it's set to false by another thread -
thus it doesn't know whether RunGpuLoop is still executing (in which
case it can't just reset the pointers, because it may still be using the
buffer) or not (in which case the condition variable it normally waits
for to avoid the previous problem will never be signaled). However,
SyncGPU's caller PushFifoAuxBuffer wasn't aware of this, so if the
buffer was filling at just the right time, it'd stay full and that
function would complain that it was about to overflow it. Similar
problem with ReadDataFromFifoOnCPU afaik. Fix this by returning early
from those as well; other callers of SyncGPU should be safe. A
*slightly* cleaner alternative would be giving the CPU thread a way to
tell when RunGpuLoop has actually exited, but whatever, this works.
|
|
This lock isn't required any more as our FlushGpu garanty to block until the GPU is idle
|
|
|
|
|
|
Now it's done without a busy loop
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
May fix crashes in rare cases.
|
