- ReImplementing Single Core Mode like Dual Core Mode Style.
- Stage 1: My goal is, we have the Fifo, CommandProccessor code the more clear, maintenible and documented possible. When I quit dolphin I want any developer can continue with the work only reading the code.
* Big Refactoring: A lot of functions was changed the names, and modularized.
Now the FifoLoop and CatchUpGPU does not exist, was replaced by RunGpu() and RunGpuLoop().
The general idea is modeling the code like the real HW. The fifo is only a buffer where the Write Gather Pipe write the commands and from the Graphic Processor read these.
* Big Clean UP a lot of obsolete code and comments was deleted, like DcFakeWachDog, "Fifo very soon hack", etc.
In the stage 2, I will refactoring more code doing emphasis in the division of CommandProcessor, Fifo, Gpu Emulation. Beside I will comment all functions and variables in the code (Don't worry I will ask for English help for this part ;) )
Please test a lot SC mode and DC mode :)
Thank you so much for testing always and the patience. I don't like broke your favorite game but... you must believe me this part is very sensible, I only try to contribute for have a better and stable dolphin emulator.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7185 8ced0084-cf51-0410-be5f-012b33b47a6e
- This game read the CPRead pointer when the GP is processing data and after detach the fifo and attach again an use this pointer for continue, so implement fifo.SafeCPReadPointer pointer.
- fifo.SafeCPReadPointer is updated when (FAKE_GetFifoEndPtr() - g_pVideoData) == 0) to have a pointer without GFX Commands Cut in the beginning of 32 block.
- Reset video buffer when the CPReadWriteDistance is written by the software.
- This commit is experimental please test a lot your games.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7165 8ced0084-cf51-0410-be5f-012b33b47a6e
- In the Command Processor Control Register when GPReadEnable is OFF, wait until the fifo lopp finish with thi actual 32 bytes block. This is necessary to have Safe Disabble GP Read in this way AbortFrame is performed by the software, beside this can help to have accurate GPReadEnable OFF.
Please test Metroid Prime 1/2, Guilty Gear XX, X men gc, SMG, and shuffle you can test Harry Potter Prince for WII. :)
PD: The fifo code need a clean very soon.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7158 8ced0084-cf51-0410-be5f-012b33b47a6e
I think that isFifoBusy bring better sync with VI (video interface) because the CPU emulated threads are waiting for DrawDone in BP Register. So, I do some modifications.
1) Rename "IsFifoBusy" by "isPossibleWaitingSetDrawDone"
2) Only activate isPossibleWaitingSetDrawDone when bFF_GPLinkEnable is true in fifo loop "Inmediate mode" that is because in theory this drawsync function is using in this mode.
3) Deactivate isPossibleWaitingSetDrawDone also in SetFinish in PixelEngine, beside when 32 block is finish.
Please regression in yours games thats can bring some FPS more above all with VPS frame limiter ON (Auto, 60, 50, etc).
- Fix waiting in AbortFrame(), please test mp1/mp2 is fixed again.
Good look!
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7123 8ced0084-cf51-0410-be5f-012b33b47a6e
Properly pause the core when saving/loading savestates, previously we used PowerPC::Pause() and Start() which only update the state but doesn't properly set m_StepEvent and caused random hangs.
Fixed hang when creating a savestate while the game was paused or in Frame Advance mode, now the thing works (just remember to press play duh).
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6992 8ced0084-cf51-0410-be5f-012b33b47a6e
- Reimplemented AbortFrame. Now the Write Gather Pipe buffer is reseted and Read Write Distances is reseted before the game do it instead the process all GP CPRWDistance for prevent CP wrong pointers.
This fifo reset should be more accurate, efficient and smooth the FPS when happens. Please, test regresion of SMG1 and SMG2 or others games with FIFO RESETS.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6971 8ced0084-cf51-0410-be5f-012b33b47a6e
1) What is the FIFO? The fifo is a ring queue for write (CPU) and read (GPU) the graphics commands.
2) What is the Brakpoints? The breakpoint is the FIFO mark to allow parallel work (CPU-GPU) When the GPU reached the breakpoint must stop read immediately until this Breakpoint will be removed for the CPU.
3) What is an overflow? The CPU write all room FIFO possible, and like a ring overwrite commands not processed yet.
4) ¿Why you have an overflow? In theory should not have an overflow never because the fifo has another mark (High Watermark) When the CPU Write reach this mark raise a CP interruption and the FIFO CPU WRITES should stop write until distance between READ POINTER AND WRITE POINTER will be equal to another mark (LO Watemark to prevent and overflow.
5) ¡So if impossible why you have overflows? Simple, the CP interruption is processed later and the Overflow happens. (there is a lot of theories about this)
6) ¿Why is no so simple like when CPU WRITE POINTER is near to the end of the FIFO only process pending graphics command?
Because when this happens sometimes we are in BREAKPOINT and is IMPOSIBLE process the graphics commands.
- This HACK process the pending data when CPU WRITE POINTER is 32 bytes before the end of the fifo, and if there is a Breakpoint force the situation to process the commands and prevent an overflown.
In theory you have not see "FIFO is overflown by GatherPipe nCPU thread is too fast!" anymore. But if you have a hang in game where you had this please read the NOTICE LOG in user\logs, I've added this message "FIFO is almost in overflown, BreakPoint" when the hack is activated. (I will delete this message very soon)
Good Luck!! PD: Shuffle sorry for the large commit description :P
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6662 8ced0084-cf51-0410-be5f-012b33b47a6e
- Improved the GP Register Status: now this is all the time from the fifo loop.
- Improved the Interrupts manage:
1) Removed All UpdateInturrupts from CommandProcessor Writes and Read.
2) now the CP interrupts are schedule from the video thread and the fifo loop waiting until this happens
3) considering Inmediate mode for the CP interrupts
3) Implemented Interrupt CP Cache State
4) Implemented only Overflow interrupt in GatherPipeCheck because this need to be detected quickly.
- Implemented Overflow handling like a real HW, when Hiwatermark interrupt happens this write ClearRegister with True en HI and False in LO (FifoIntReset) after that a Control Register is writed and the FIFO is processed to LO Watermark.
- Removed all ugly code from LO and HI watermark manage
- Removed all ugly code from BP manage
- Change >= by == in the BP clauses
- Removed speed hack (1024 chunk) for better GP Status Control.
- Commented GXSetGPFifo very soon hack
- Commented FackWatchDog hack
- Commented FIFO_RW_DISTANCE = WritePointer hack
This is the beginning and the base for the future., If this broke your favorite game my apologize, only report this and will try solve it. If you have a Overflown don't worry, I've implemented the real solution code using the Overflow Interruption only need continue working for a perfect protection. Why I did it? Because is preferable a accurate and clean fifo instead hack y fifo for improve that. Thanks to DONKO for you awesome Video Plug in and skid for the chatting. PD: I have 7-10 fps more in the star fox video. bye :P
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6554 8ced0084-cf51-0410-be5f-012b33b47a6e
Most of the code dealing with the LogTypes namespace was C which lead to a
lot of nonsensical casting, so I have dumbed LOG_TYPE and LOG_LEVEL down to
plain C even though the move of wiiuse into Source means we don't currently
call GenericLog from C.
Set logging threshold to MAX_LOGLEVEL at startup so debug builds will also
p rint debugging messages before the GUI is running.
For some reason the way we use SetDefaultStyle doesn't play nice with wx 2.9
so we just get the default black text on a black background. Using a gray
background works around that problem, but I found it to also be much easier
on the eyes so I have switched the background color on all versions.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6528 8ced0084-cf51-0410-be5f-012b33b47a6e
Plus: I added a _assert_msg_ in FIFO loop when the WriteDistance is negative. Please if that happens report it, this can help to solve strange issues with wrong WriteDistances.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6495 8ced0084-cf51-0410-be5f-012b33b47a6e
In this way it prevents wrong fifo.CPReadWriteDistance in the future. That should fix RE0 Issue 2846 and others "Warning: GFX FIFO: Unknown Opcode (0x4d)" in dual core mode.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6485 8ced0084-cf51-0410-be5f-012b33b47a6e
(those originating from a thread other than the gpu thread)
glxMakeCurrent is supposed to error out when the context is
still current in another thread. NVIDIA handles that, but mesa3d errors.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6054 8ced0084-cf51-0410-be5f-012b33b47a6e
- fix numerous warnings
- make some variables unsigned
- remove redundant code and header inclusions
- make code more compact in lots of cases
Committing some additional changes by myself:
- additional header cleanups
- cleanup DX11 initialization/shutdown process (hinted at by avindra)
- Remove the cgD3D9 stuff from Externals since it's no longer needed
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5903 8ced0084-cf51-0410-be5f-012b33b47a6e
Dual Core sync fix.
When the FIFO is processing data we must not advance the cpu cycles in CoreTiming because in this way the VI will be desynchronized. So, We are waiting until the FIFO finish and while we process only the events required by the FIFO.
This should fix Issue 2072 .
This affect to all games in dual core mode.
Please, You can test all games with VPS limiter auto, 60, 50 depending of the game and compare with prev revision.
For example now NSMB in the video Intro has 60 fps (prev 30 fps) :D or SMG does't need anymore FPS Limitter Hack to get 55-60 fps
Beside the slowdowns now are more softly and the fps more stables because the VI sync is almost perfect.
The Core Timing and Fifo modifications are delicated. Please report if this hang any game. Don't forget check with prev revision.
Enjoy it! Thanks to Rodolfo for teach me all about dolphin.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5777 8ced0084-cf51-0410-be5f-012b33b47a6e
By now I'm pretty sure some games are written in multi-thread, and they depend on Watermark to suspend/resume their threads.
So without Watermark, they will never work.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5709 8ced0084-cf51-0410-be5f-012b33b47a6e
Improved dual core mode for "Metroid Prime 2", "Star Fox Adventures", etc.
I should have committed this long time ago, but I don't have every game to test compatibility... Any way, better late than never.
PS: If any regression observed, feel free to revert this rev.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5681 8ced0084-cf51-0410-be5f-012b33b47a6e
Enable the thread by adding this line to the video plugin ini files, "User\Config\gfx_dx9.ini" and "User\Config\gfx_opengl.ini":
UseFIFOThread = True
The line should be added under the UseXFB line.
To disable the FIFO thread, use this line:
UseFIFOThread = False
If the line is not in the ini file, the default is disabled (i.e. False).
The FIFO thread causes an error when the OpenGL plugin is used. The D3D plugin works.
Only top left quarter of the screen can be seen when rendering to main window. The entire screen can be viewed when running in a window.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4930 8ced0084-cf51-0410-be5f-012b33b47a6e
2. Fixed a bug (for Win 32bit) that reports "No possible memory base pointer found!" even when there IS valid memory base found.
3. Made Metroid Prime 2 (maybe also other games) boot
PS: There is definitely some initialization problem with Dolphin (not found exact location yet), which prevents Metroid Prime 2 from first time booting (If you boot some other GC game first, stop it, then MP2 can boot without problem).
So I added an instant BP hack that can make MP2 boot even at first time.
And I've tested all my games to guarantee it won't break any game that already boots before this hack.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4795 8ced0084-cf51-0410-be5f-012b33b47a6e
Now the frame limiter yields on CPU thread, not as before on GPU thread mistakenly
2. Fixed clear of VI interrupts
I guess VI interrupts are not used at all, because they were never cleared before
3. Made GPU thread 0% processor usage when paused whatever your active config is.
I tried the event approach but somehow the thread resume latency is excessively long (Who can tell me why?)
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4790 8ced0084-cf51-0410-be5f-012b33b47a6e
"VideoFifo_CheckEFBAccess()" & "VideoFifo_CheckSwapRequest()" should be moved to a more suitable place than inside function "Fifo_EnterLoop()", which wastes considerable amount of CPU time (exhausting one core completely even when paused) and also makes VPS inaccurate.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4778 8ced0084-cf51-0410-be5f-012b33b47a6e
This also fixed Ikaruga, not sure whether it could fix Metriod Prime. If not, how about disabling EFB copy?
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4777 8ced0084-cf51-0410-be5f-012b33b47a6e
2. Fixed Issue 1909
Multi-Nunchuck control problem
3. Updated SYSCONF, which should enable games that require MotionPlus, such as "Wii Sports Resort"
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4773 8ced0084-cf51-0410-be5f-012b33b47a6e
sl1nk3.s