dok's "FIFO is overflown by Gatherpipe" fix

[Jack Frost]

Oh, welcome back marcos.
There you go: http://pastie.org/1303701

[marcosvitali]

The code looks very interesting. That eliminate my isFifoBusy HACK If this code works fine. I can implement my project with FIFO in other thread because this patch should be solve all timing issues that I had

[Xtreme2damax]

Welcome back marco.

Quite a few fifo/vi issues fixed, as far as I know the issue with RECVX is still not fixed. Dlist caching is still buggy, but better now than it was.

Quote:I can implement my project with FIFO in other thread

Does that mean placing the fifo on a separate thread like Skid tried doing once before? If done properly that could benefit multi-core/multi-threaded processors by keeping the fifo seperate from the Wii GPU and PPC processor threads. Last time Skid tried that there was no real gain by doing this, but that was a while back so I don't know about now.

A quick poke regarding idle skipping which still isn't working with this patch. Issue with Crash Bandicoot - Wrath of Cortex needs to be fixed as well, which now has these fifo overflown errors and crashes that this game never had previously. I don't see why this couldn't be committed to svn after those two minor issues are addressed.

[marcosvitali]

Xtreme: Rodolfo and Me have new Ideas. Dont worry. The Video thread ALWAYSSSSSSSSSSSSSSS is one. The multithread idea is only for advance work like Process vertex in background or jiting VideoOPDecoding or improve fifo loop. Skidau in the past launch a lot of video thread thats why it didnt work. Beside DListCache is not related with these improves.

[Xtreme2damax]

I am certainly looking forward to this for one. It seems that Tino/Rodolfo doesn't have a lot of time these days, but I will be awaiting this as patiently as can be.

[ector]

If I were to rip out the multithreading code and do it all over again, I would try the following: do a first simple parse of the GPU commands on the CPU thread, doing things like responding to breakpoint etc immediately, while actually putting the gfx instructions like loadbp or drawprimitive on a queue, that a graphics thread then reads from, decodes the vertices, and executes. That would take a lot of the randomness out of things. It would only need to synchronize the draw thread fully when doing things like copying from EFB to RAM, or hitting breakpoints and tokens.

I have no idea if this would be faster in practice, or if I'm missing something that would make it not work though.

[Jack Frost]

(11-17-2010, 07:45 AM)Xtreme2damax Wrote: Does that mean placing the fifo on a separate thread like Skid tried doing once before? If done properly that could benefit multi-core/multi-threaded processors by keeping the fifo seperate from the Wii GPU and PPC processor threads. Last time Skid tried that there was no real gain by doing this, but that was a while back so I don't know about now.

(11-17-2010, 09:55 AM)ector Wrote: If I were to rip out the multithreading code and do it all over again, I would try the following: do a first simple parse of the GPU commands on the CPU thread, doing things like responding to breakpoint etc immediately, while actually putting the gfx instructions like loadbp or drawprimitive on a queue, that a graphics thread then reads from, decodes the vertices, and executes. That would take a lot of the randomness out of things. It would only need to synchronize the draw thread fully when doing things like copying from EFB to RAM, or hitting breakpoints and tokens.

drk also said that on IRC, so I'd go with doing as much work as possibly off the video thread, to avoid unnecessary synchronization and/or buffer copying.
So, count me in for the "no further thread for it" idea. When implemented correctly, it can be moved out into another thread easily anyways

[Xtreme2damax]

Patch needs a quick update, there was a change to /JIT64IL/JITIL.cpp recently. I manually patched/updated the file myself, but I'm not sure if I did it correctly.

[Xtreme2damax]

:Edit: Nevermind, the error exists even on unpatched builds with JITIL, don't know how I missed that. Still, this patch makes NSMB slow especially since idle skipping can't be enabled with the patch.

[Legend80]

We need to get this thing committed so it doesn't keep depreciating...hopefully the issues with Idle skipping and CB Wrath of Cortex can be sorted out. Maybe with a fresh compile of the latest source and this patch will yeild different results than before?