Commit Graph

18 Commits

Author SHA1 Message Date
Marcos Vitali c7ae0eb0d1 Big Fifo Commit Part2: Now the fifo is more stable than my first commit, so is time...
- 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
2011-02-17 04:25:21 +00:00
Glenn Rice 0ae8d33149 Some work on changing comments, log messages, and variable and function names to reflect that the plugins are not plugins anymore.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7170 8ced0084-cf51-0410-be5f-012b33b47a6e
2011-02-14 02:18:03 +00:00
Marcos Vitali 86278642dc Experimental commit and one fix for my last commit.
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
2011-02-10 04:47:02 +00:00
skidau 855f97841d Paused the video thread while a save state was being created or loaded. Performed the save state operation after the fifo became idle. Saved the interrupt status of the video thread into the save state. This helps stabilise the save states in dual core mode in games like Super Mario Galaxy.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@7112 8ced0084-cf51-0410-be5f-012b33b47a6e
2011-02-08 10:37:47 +00:00
Jordan Woyak fbaf965995 Eliminated the plugin interface. Merged DX9/DX11/OGL video plugins into Dolphin. It could still use a lot of cleanup. Lots of things are still named "plugin". Software renderer is temporarily disabled until it gets some namespaces. I only updated vs08/10, Linux/OSX builds are broken.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6996 8ced0084-cf51-0410-be5f-012b33b47a6e
2011-01-31 01:28:32 +00:00
Marcos Vitali 695010520f More FIFO work, HACK Solution for extreme overflow on breakpoints.
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
2010-12-27 02:55:35 +00:00
Marcos Vitali 5fd9951649 - I've implemented cache of interrupt states for PEFINISH and PETOKEN
- 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
2010-12-13 07:56:54 +00:00
Marcos Vitali a9ca9cfd9b BIG FIFO Commit PART 1! Sometimes you need to write everything from 0, so 10 days later Ive rewrited some parts of the FIFO in Dual Core mode. Is pending use the same code for SC mode.
- 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
2010-12-11 12:42:55 +00:00
Shawn Hoffman 18be8ffa6e Replace all bitfields which were only declared with "(un)signed" with their actual types. Let me know if I missed any. It would also be a good idea to test this commit in both x64 and x86.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@6232 8ced0084-cf51-0410-be5f-012b33b47a6e
2010-09-27 04:29:51 +00:00
Marcos Vitali 3b7a6ce336 I've observed that "FIFO is overflown by GatherPipe" is not real overflow.
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
2010-08-10 07:25:35 +00:00
Marcos Vitali 10b5d2371c My first commit :D
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
2010-06-24 13:28:54 +00:00
ayuanx 673b9ac179 Implemented accurate BP and accurate Watermark, this should eventually retire FAKE_Watchdog.
AbortFrame is not implemented yet.

git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@5699 8ced0084-cf51-0410-be5f-012b33b47a6e
2010-06-14 21:55:40 +00:00
Shawn Hoffman 4a0c8fc0c9 Hg:
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
2010-06-09 01:37:08 +00:00
ayuanx 40f4dd30c2 Fixed Issue 1711 (a bug that prevents some games from booting)
Thanks to chuvit's help

Added safety check for CFrame::Update

git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4759 8ced0084-cf51-0410-be5f-012b33b47a6e
2009-12-31 16:25:12 +00:00
ayuanx 151ff28ab7 Fixed mem leak caused by not releasing pad & wiimote plugin when shutdown
Fixed main frame crash after shutdown

git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4755 8ced0084-cf51-0410-be5f-012b33b47a6e
2009-12-30 14:37:12 +00:00
ayuanx 0ae7be2c1c Since we have been employing the FIFO BP hack for so long time, at least let's make it a decent hack.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4699 8ced0084-cf51-0410-be5f-012b33b47a6e
2009-12-16 17:05:30 +00:00
ayuanx 66b1eb1f08 Does anyone know any game that requires the "Clear FIFO BP on Rising Edge"?
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
2009-12-14 15:50:31 +00:00
donkopunchstania 56214e9103 Moving pixel engine and command processor from core to video common. This will break previous save states. Adds decoding single pixels to texture decoder.
git-svn-id: https://dolphin-emu.googlecode.com/svn/trunk@4391 8ced0084-cf51-0410-be5f-012b33b47a6e
2009-10-10 21:19:39 +00:00