- 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
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
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
- I've implemented calling to ProcessFifoEvents when is there is a pending event in the main queue from CP, PE & GP
- I've implemented FifoIntReset(TRUE, TRUE) in write Clear Register.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6572 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
Really that happens because the fifo.CPReadWriteDistance is negative.
Example: CPReadWriteDistance: -864 CPEnd: 10092672 fifo.CPBase: 9568416
In SMG this is because PI_FIFO_RESET is writing and after fifo.CPReadWriteDistance will be setted to 0.
To Prevent that, I've Implemented AbortFrame function in the CommmandProcessor. It should fix overflown because of that.
Note: There is other issue (Issue 2846) where the fifo.CPReadWriteDistance is negative too but the effect is different.
I'm working to solve this.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6083 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
enable newline normalization
get revision number via `hg svn info` for svnrev.h
ignore incremental/generated binary files (windows/VS at least)
leave a comment if some files need native eol set in svnprops
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5637 8ced0084-cf51-0410-be5f-012b33b47a6e
Because commenting out this behavior fixes Silent Hill Shattered Memories.
If this commit breaks any game, please report.
PS: There is a EnterCriticalSection in fifo.cpp, which performs the Read Access, but there is no EnterCriticalSection in CommandProcessor.cpp which performs the Write Access, so how can we guarantee the Write Access is atomic?
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4694 8ced0084-cf51-0410-be5f-012b33b47a6e
Marcos Vitali