Commit Graph

28 Commits

Author SHA1 Message Date
Rohit Nirmal b030d29067 Silence some -Wswitch-default warnings. 2014-12-11 22:23:05 -06:00
skidau f65bb10c93 Merge pull request #1308 from kayru/shader_generator_write_opt
Workaround for MSVC not optimizing away Write() in GeneratePixelShader
2014-10-20 17:15:53 +11:00
Yuriy O'Donnell d23da7dbef Added __forceinline to AlphaTest::TestResult() to make MSVC inline it 2014-10-17 21:50:41 +02:00
Yuriy O'Donnell 2e4667caaa D3D: Moved render state cache into separate source files.
Refactored  StateCache::Get() to early out for narrower indentation.
Added comments to clarify ownership of objects returned by  StateCache::Get().
2014-10-15 20:22:39 +02: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
Tony Wasserka 1d23c2ca8b GPU: Only load the relevant color components upon writes to the tev color registers.
The other two components need not be valid upon write, hence loading them results in glitches.

Fixes issue 6783.
2014-09-21 10:38:22 +02:00
Lioncash 91438fa9e7 VideoCommon: Make zfreeze in GenMode 1 bit in size 2014-09-20 14:30:41 -04:00
Rohit Nirmal fbc64984ca Include CommonTypes.h instead of Common.h. 2014-09-08 15:39:58 -04:00
Lioncash 4af8d9d248 VideoCommon: Clean up brace placements 2014-08-30 18:06:45 -04:00
Lioncash 776e36b10a Fix a typo in a BP register name (BPMEM_TX_SETLUT_4 -> BPMEM_TX_SETTLUT_4).
Also fixed the alignment of the register values.
2014-06-02 02:26:30 -04:00
Lioncash c96407bd2a Make GetBPRegInfo just take two strings as parameters
Gets rid of the size parameters.
2014-05-29 19:44:14 -04:00
Jasper St. Pierre 2f122ea63c BPMemory: Fix "DISPLAYCOPYFILER" typo 2014-05-20 11:15:10 -04:00
magumagu 2e464800bc VideoCommon: correctly compute whether an indirect texture stage is active.
This is consistent with the implementation in PixelShaderGen.
2014-05-04 22:44:10 -07:00
Tony Wasserka 762572a08c BPMemory: Fix GenMode using an incorrect number of bits for the number of color chans. 2014-04-21 22:47:08 +02:00
Tony Wasserka 16d3dbc5ea BPMemory: Use BitField for the GenMode fields. 2014-04-21 22:34:23 +02:00
comex b5654a2464 Don't cast -1 to enum to represent a missing value.
This is undefined behavior in C++, and a clang warning suggests it is
actually producing bad code as a result:

../Source/Core/VideoCommon/BPFunctions.cpp:164:45: warning: comparison of constant 4294967295 with expression of type 'PEControl::PixelFormat' is always false [-Wtautological-constant-out-of-range-compare]
        if (new_format == old_format || old_format == (unsigned int)-1)
2014-03-30 01:40:06 -04:00
Tony Wasserka c6070b94ce BPMemory: Fix an enum to use u32 as its underlying type. 2014-03-26 10:02:57 +01:00
Tony Wasserka 16105db709 BPMemory: Make use of BitField in a number of structures. 2014-03-25 23:57:58 +01:00
Tony Wasserka 8941f19cdb BPMemory: Expose the pixel_format and zformat fields in PE_CONTROL as enumerations. 2014-03-25 23:57:58 +01:00
Tony Wasserka 77a7bab5ae BPMemory: Use the new BitField class in two selected structures. 2014-03-25 23:57:57 +01:00
Tony Wasserka fa7173d099 PixelShaderGen: Store tex scale as an integer. 2014-03-14 22:32:30 +01: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
Lioncash 2afe215271 Convert all includes to relative paths. 2014-02-18 02:19:10 -05:00
Lioncash 3fd87a7636 Second and final pass of clearing out tabs. 2014-02-17 02:19:41 -05:00
lioncash d2038049f5 Replace all include guard ifdefs with "#pragma once" 2014-02-10 18:07:16 -05:00
Lioncash ebb48d019e Clean up some struct indentations
Also cleaned up the indentations of some variable declarations.
2014-02-09 19:40:11 -05:00
Pierre Bourdon ed67d1ae2f Fix the Zelda: The Wind Waker heat effect glitch.
Let's talk a bit about this bug. 12nd oldest bug not fixed in Dolphin, it was a
lot of fun to debug and it kept me busy for a while :)

Shoutout to Nintendo for framework.map, without which this could have taken a
lot longer.

Basic debugging using apitrace shows that the heat effect is rendered in an
interesting way:
* An EFB copy texture is created, using the hardware scaler to divide the
  texture resolution by two and that way create the blur effect.
* This texture is then warped using indirect texturing: a deformation map is
  used to "move" the texture coordinates used to sample the framebuffer copy.

Pixel shader: http://pastie.org/private/25oe1pqn6s0h5yieks1jfw

Interestingly, when looking at apitrace, the deformation texture was only 4x4
pixels... weird. It also does not have any feature that you would expect from a
deformation map. Seeing how the heat effect glitches, this deformation texture
being wrong looks like a good candidate for the problem. Let's see how it's
loaded!

By NOPing random calls to GXSetTevIndirect, we find a call that when removed
breaks the effect completely. The parameters used for this call come from the
results of methods of JPAExTexShapeArc objects. 3 different objects go through
this code path, by breaking each one we can notice that the one "controlling"
the heat effect is the one at 0x81575b98.

Following the path of this object a bit more, we can see that it has a method
called "getIndTexId". When this is called, the returned texture ID is used to
index a map and get a JPATextureArc object stored at 0x81577bec.

Nice feature of JPATextureArc: they have a getName method. For this object, it
returns "AK_kagerouInd01". We can probably use that to see how this texture
should look like, by loading it "manually" from the Wind Waker DVD.
Unfortunately I don't know how to do that. Fortunately @Abahbob got me the
texture I wanted in less than 10min after I asked him on Twitter.
AK_kagerouInd01 is a 32x32 texture that really looks like a deformation map:
http://i.imgur.com/0TfZEVj.png . Fun fact: "kagerou" means "heat haze" in JP.

So apparently we're not using the right texture object when rendering! The
GXTexObj that maps to the JPATextureArc is at offset 0x81577bf0 and points to
data at 0x80ed0460, but we're loading texture data from 0x0039d860 instead.

I started to suspect the BP write that loads the texture parameters "did not
work" somehow. Logged that and yes: nothing gets loaded to texture stage 1! ...
but it turns out this is normal, the deformation map is loaded to texture stage
5 (hardcoded in the DOL). Wait, why is the TextureCache trying to load from
texture stage 1 then?!

Because someone sucked at hex.

Fixes issue 2338.
2014-01-05 11:33:15 +01:00
Jasper St. Pierre 34692ab826 Remove unnecessary Src/ folders 2013-12-31 14:03:19 -05:00