Emulator

So further testing has concluded that the flickering is caused by the typical XFB issue. When XFB is set to real (Native) flickering is gone however massive FIFO errors. When XFB is set to Virtual (Hi-Res) FIFO errors are gone but randomly the flickering starts. Sorry I didn't report this earlier I am new to the XFB issues.

Hmmm, fifo issues with real xfb. Somebody CC marcos.

Have you tried turning progressive scan off?
Is this PAL or NTSC?

I don't experience this issue.

Ok I will see the posibbles FIFO issues reported in these days, SpiderTE...@gmail.com: Could you describe "massive FIFO errors"?

I don't see any flickering (WRXE08 - r7459 Jit32 - WinXP 32 bit, hd4850)

Ok tried both PAL and NTSC both have this issue. Also I have taken more notice to when it happens. It seems to only happen if my frames drop to below 30. Even for a brief second to load the next room and back up to 60FPS the flickering continues. seems to be some sort of desyncing issue. When I 1st play the game from first boot my frames will drop (below 30 for like 2 secounds) when the ship crashes into the cave which then causes flickering. After game close but keeping dolphin open and re running the game my frames stay at 60 until you shoot the 1st door and frames drop again (flickering appears again). after game close again and re open my frames dont drop until you drop into the next cave (more flickering). Obviously game was in cache still. So to the 2 that haven't experienced this issue, how is your frames? May not be able to report back until later today.

As to the FIFO errors:

GFX FIFO: Unknown Opcode (0x7f).
...
...
...
Dolphin will now likely crash or hang. Enjoy.

Illegal command 7f
CPBase: 0x054d920
CPEnd:0x005as900
CPHiWatermark:0x0005c000
CPLoWatermark:0x00050000
CPReadWriteDistance:0x0001e380
CPWritePointer:0x0056d700
CPReadPointer:0x0054f380
CPBreakpoint:0x0054f3a0
bFF_GPReadEnable:false
bFF_BPEnable:true
bFF_BPInt:true
bFF_breakpoint:false

Infinite repeat of these popups. I have to Force Close.

Ok give me this week, I will back and reponse why that is happens.

My frames are ok...

@ hatarumo...@hotmail.com & NaturalV...@gmail.com

Can you do me a favor and try everything you can to drop your framerates to below 15fps and see if the flickering occurs. Crank everything up. Max whatever you can. Turn on whatever settings cause slowdowns. I'm just saying because for me it only occurs when my Frames drop. Just keep playing until your frames drop. You are saying it doesn't happen for you. Maybe you've got better hardware than I do and your Frames never drop. My average Frames for this game is 60. but when it has to load a lot of textures, my frames drop for like 1 second and then back up to 60fps. And that's when the flickering occurs that never stops. It even happens when I switch to scan things. Also for the record I did try to crank everything to bare minimum except for XFB because of FIFO errors. The Result was I got further in the game until my frames dropped again.

I tried to put the framelimiter to 20 and I still get no flickering. For me flickering occurs only if I turn on XFB (virtual).
Instead if you mean visual tearing try to turn on Vsync.

@ hatarumo...@hotmail.com

I'm confused. So you get flickering or don't get flickering. And no I don't mean tearing. I know the difference between the screen strobing like I'm in a rave, and a tearing issue. But for the record I did try Vsync. Didn't help.

As I said I don't get any flickering; flickering occurs only if I manually enable XFB (virtual) in the graphic configuration, so keep it disabled as it is by default.

OK so I'm going to try this one more time....

hatarumo...@hotmail.com, do me a favor. Read the Issue I posted, then read my 1st comment to the issue. Then tell me if you experience the same issue.

XFB seems to break this game, so you don't have to enable it.

This issue is similar to issue 3902
caused by r6554

Not related with Issue 3902, this issue still here but still r6554 is a culprit

Console writes
"HW\ProcessorInterface.cpp Fifo Reset" by every flick

Yep i see, i saw AbortFrame in ProcessorInterface under Fifo Reset, but why everything worked fine before 6554?

This question is very dificult to response. If you are in REAL HW, the Abort Frame is good, is like a skip frame. Maybe now the scenary to this game is different that 6554. But I cant say this scenary is bad for dolphin. I only can say this scenary produce AbortFrame for MP. In Real HW AbortFrame are goood. But in dolphin are slow.... You must think in this the game only want to do a favor skip frames but dolphin is really slow for that.

Damn, why i didn't checked this before...
Tested SC mode, not a single flick
this issue is definitely a DC mode regression

I've made some tests
and actually flicks happen after

void WaitForFrameFinish()
{
while ((fake_GPWatchdogLastToken == fifo.Fake_GPWDToken) && fifo.bFF_GPReadEnable && fifo.CPReadWriteDistance)
{
s_fifoIdleEvent.Wait();
}

fake_GPWatchdogLastToken = fifo.Fake_GPWDToken;

}
was commented out in 6554, of course it looks hacky, but nothing to do with Abort frame

For sure, this one relied on gp_watchdog before it was removed in 7185

Autoran, forget this is not related directly. This Events happens in each VI interrupt and ask there is a token in this VI interval if not ProcessAllFifo until there is a token. In my past investigation the VI can be related with Fifo_Reset but I am not sure. Anyway when have time I will reasearch that for you. Thanks for all.

I'm very appreciate your work, thanks for explanation, just wanted to know for sure and learn these two commits 6554 and 7185 all this time :)

First of all, Single Core mode still doesn't have this issues

Issue 5185 has been merged into this issue.

Issue 5431 has been merged into this issue.

Issue 5448 has been merged into this issue.

All three issues maybe look different but all have the same nature, no matter if that black bars, XFB flicks or geometry flicks, all goes from the same code

5431 is not even remotely similar to this.

Found the part of code from r6554 that makes these issues fixed, all of them, black bars, xfb and geometry cache flicks. The games rely on DC watchdog hack and some Fifo code that was removed, SC mode works fine even on recent revs, that makes me think that some DC timings stuff needs to be implemented since there no WatchDog hack.
Here's the patch, but unfortunately it works only up to rev7184 for now need more time to investigate rev7185

I am quite sure that most of the code in the patch was removed because it was not accurate. The only part that I think is questionable is this line:

Common::AtomicStore(_fifo.bFF_GPReadEnable, false);

I can do more tests with this line in the upcoming days.

Not sure this should have been marked as Fixed. This "fix" is INSANELY slow, but with EFB to Texture allowed and 1x Native on DX9, I can run this fullspeed. Need that for testing this. And microstuttering STILL occurs in my usual testing route, but the black bar problem and squishing appears corrected. So the flickering that this problem is about appears to still be present. Ask me about it in the IRC, I'd like some instructions for making a fifo log of this.

Alright skidau, I have some test results for Metroid Prime 3. What I said previously was, well, wrong. It is slow, granted, but not as bad as I thought. And what I thought was stuttering was some sort of loading-based slowdown. Probably a secondary issue. No FIFO errors occurred from it, it appears in different spots than the fifo bugs, it doesn't cause the black bar squishing, and it occurs the exact same spots in the exact same manner in master. I'm assuming it's some sort of unrelated slowdown.

First of all, single core fixes the black bar and microstuttering problems, even in the flipping so badly it's nearly unplayable builds before 3.5-380 and the IPC_HLE changes. I tested on 3.5-358. Ye Olde fifo test, running out the door from the save station in the Olympus and onto the bridge really fast, caused guaranteed fifo resets and black bar problems in 3.5-358. Single core? Didn't happen. The other trick is to flip back and forth between fullscreen and windowed really fast, a trick that works reliably on master even after the IPC_HLE changes. Single core in 3.5-358 prevented that too. Also tried it in FIFO-BP 3.5-415 (dual core unsynced) and in 3.5-394 (single core), and both didn't have the problem. So, Single core is guaranteed to prevent this.

Now, onto the Fifo-BP 3.5-415. It definitely fixes it. The alt-alter rapidly test did not make it derp at all. Running around and doing whatever I could to screw it up, and nothing made the black bars appear or the video do that characteristic "reset", that fifo resets have.

Here are my performance testings. All are on my computer: Core i5 3570K @ 4.7ghz, more or less the strongest CPU testing till Haswell appears. All tests used DSP LLE on Thread, D3D9, Per-pixel lighting (habit), no anisotropic filtering, scaled EFB copy, Fast texture accuracy, and disabled xfb. EFB to texture was allowed in the gameINI for comparing EFB to Ram and EFB to Texture performance levels. And all tests use FIFO-BP 3.5-415. Here are the tests and results.

Test 1: 1x native EFB to Texture - Save station on the Olympus, before seeing the hunters for the briefing. Immediately after entering, not moving off the save station or changing the view.

*Single Core unsychronized - 58fps
*Dual core sychronized - 63fps
*Dual core unsychronized - 74fps

Test 2: 1x native EFB to Texture - Before the briefing early in the game, walking in front of the guy working the console on the bridge of the Olympus, between the console and the railing, and staring out the window.

*Single core unsychronized - 50fps
*Dual core sychronized - 57fps
*Dual Core unsychronized - 72fps

Test 3: 3x native EFB to Ram (no cache) - Save station on the Olympus, before seeing the hunters for the briefing. Immediately after entering the game, not moving off the save station or changing the view (looking at the door).

*Single Core unsychronized - 58fps
*Dual core sychronized - 62fps
*Dual core unsychronized - 74fps

Test 4: 3x native EFB to Ram (no cache) - Before the briefing early in the game, walking in front of the guy working the console on the bridge of the Olympus, between the console and the railing, and staring out the window.

*Single core unsychronized - 50fps
*Dual core sychronized - 56fps
*Dual Core unsychronized - 72fps

I'll do a test on FIFO-BP version differences speeds later. But I can't download much with this net right now. If you have more tests feel free to ask.

Erm... sorry about this, but ignore those EFB to Ram tests. Apparently enabling efb to texture in the gameini meant "use EFB to Texture of GUI". Gah. I should have just removed the line. I'll redo the EFB to Ram tests.

Alright, here we go. These are the REAL WORLD TESTS. FIFO-BP 3.5-415, D3D9, EFB to Ram cached, DSP LLE on thread, and XFB off (of course). The line that allows EFB to Texture is set to FALSE.

Test 1 - Save station on the Olympus, before seeing the hunters for the briefing. Immediately after entering, not moving off the save station or changing the view. Stay on it for a few seconds to insure stability.

Single Core unsychronized - 45-46fps
Dual Core sychronized - 47fps
Dual Core unsychronized - 72fps

Test 2 - Before the briefing early in the game, walking in front of the guy working the console on the bridge of the Olympus, between the console and the railing, and staring out the window.

Single Core unsychronized - 42fps
Dual Core sychronized - 46fps
Dual Core unsychronized - 69fps

Basically it's the same scale as the EFB to Texture tests. It provides a tiny speed bump over single core, but not much.

Btw, FIFO-BP 3.5-414 has the same speeds as 3.5-415 despite the cycle change.

Autor, can you elaborate? I did tons and tons of testing for skid with prime 1 and prime 3. What are you experiencing?

Yea those two work fine, but what do you have about Metroid 2?

Maybe it doesn't look nice to reopen it again, but it'll help avoid opening new issues

Or it's just i'm doing smth wrong, i've tried both clean x32 and x64 3.5-438 and i've got black screen in both MP1 and MP2 now as it was before with SynchronizeGPU

Well, I reproduced it. Black bar on Prime 2 remains on Fifo-BP 3.5-438 and appears during gameplay. Ouch.

Prime 3 still has the black bar in Fifo-BP 3.5-438, but it doesn't occur during gameplay. I played it for a very very long time to find that out, and it only occurred once when I hit alt-enter -20 times as fast as I could- specifically to break it. I guess Prime 2 has the same issue and can't be fixed so easily. I'll try all the tests Skid_au gave me and see if there is any impact.

At least Prime 2 is better in other ways, such as stuttering and the like. Fifo-BP is still the best branch for these games.

Do whatever you like with this issue
i have no black bars in Metroid 3 even with PAL60 the others two works as i mentioned

Tested Prime 2 further. It appears that first test I did and getting it so fast was an oddity. I've been doing an extended play testing, and not once did it hiccup during gameplay. Prime 2 was always a lot more stable than Prime 3 though. So, it seems Prime 2 very resistant to the various hiccups and derps, but a little more ready to do it than Prime 3 is. Usually it takes only a couple of alt-enters can make the black bar appear.

MaJoRoesch, all three games work for me the way you've described but only if Sync is Off

MaJoRoesch, you wrote: "I played it for a very very long time to find that out, and it only occurred once when I hit alt-enter -20 times as fast as I could- specifically to break it.", that's because you didn't cleared your ShaderCache data for too long, try to clear it before testing, and you'll see how fast this issue will appear

Metroid Prime and Metroid Prime 2 will both work with Synchronise GPU, if the GameCube BIOS is not skipped.

Just to outline what's going on through testing and taking in the IRC. Without a shadercache, such as the first run with a new install of the emulator, Metroid Prime 2 will show the black bar immediately when it hits gameplay rendering. Loading up after that with a shadercache, and the black bar will not appear, even through prolonged play. Hitting alt-enter in Prime 2 will however make the black bar appear one the first or second shot without fail. Metroid Prime 3 is not affected by the lack of shadercache, and runs great in game, with the black bar only appearing when alt-enter is rapidly pressed specifically to make the problem occur.

I noticed some variation in Prime 3 from what I remember, so I did a thorough analysis. The goal was to find which FIFO-BP revisions added stability, and which removed from it. Using black bar glitch as indicator. And remember that Prime 2 is not affected by whatever magic happened here to make Prime 3 so stable.

BTW: A curious observation. The black bar is apparently directly tied to the cache. Basically, when loading something that isn't cached, it shows the black bar. Upon reloading it, the spots that were cached run fine without causing the black bar. But anything I didn't cache, such as areas or effects I didn't see the first time, will cause the black bar. So for the unstable builds I can now predict and control when the black bar appears. Very interesting. Of course for anything over an extended period some cache culling probably goes into effect, in which case the black bar would appear, so I can't control it for extended play. But for short stuff, I can directly control when it happens.

Settings: D3D9, Dual Core, EFB to Ram, Sync off, DSP LLE on Thread

3.5-415
Without a shader cache, the black bar appears immediately upon loading. With a shader cache, the black bar does not appear immediately, but appears very quickly in normal play.
-UNSTABLE-

3.5-431
Same as previous
-UNSTABLE-

3.5-433
Same as previous
-UNSTABLE-

3.5-434
The black bar DOES NOT appear immediately upon loading with no cache. Furthermore, the black bar did not appear in 15 minutes of normal play. This build has the improved stability. It stalls in the same areas that the unstable builds do, but does not show the black bar. Alt-entering does not normally cause the black bar, but it can. One thing to note: I tested a ton of areas, and of all the testing only one spot consistently created the error with these stable builds during normal gameplay: The elysian tram to the pirate area. Could be useful for testing it.
-STABLE-

3.5-435
Same as previous
-STABLE-

3.5-436
Same as previous
-STABLE-

3.5-437
Same as previous
-STABLE-

3.5-438
Same as previous
-STABLE-

3.5-439
Same as previous
-STABLE-

3.5-515
Without a shader cache, the black bar appears immediately upon loading. With a shader cache, the black bar does not appear immediately, but appears very quickly in normal play. In other words: pretty much exactly how it was before.
-UNSTABLE-

3.5-516
Save as previous
-UNSTABLE-

3.5-517
Save as previous
-UNSTABLE-

3.5-518
Same as previous
-UNSTABLE-

3.5-519
Same as previous
-UNSTABLE-

3.5-520
Same as previous
-UNSTABLE-

Yup, MP 1 & 2 work with SyncGPU by starting with BIOS, but map goes extreeemly slow, and still unplayable see Issue 3583

Skid had a better system in FIFO-BP that didn't need SyncGPU, but it caused some conflicts so he left it out.

As of 4.0-600 (at least), it seems the black bar issues in MP2 have ended, but the game still suffers incessant flickering in dual core mode. Could someone else verify?

Still present for me in 4.0-603. One thing that causes the issue consistently is using Dolphin's screenshot functionality.

Just tried taking a screenshot myself; resulted in horrible flickering, but no black bar, just like my first test.

Oh, you must have the External Frame Buffer enabled. This behavior has been present for a long time. Disabling it will cause the black bar to return.

Yeah, I've got XFB set to Virtual. Maybe that should be added to the gameINI?

Or would that be pointless since it doesn't resolve the flickering?

Virtual XFB causes the flickering. Disabling XFB entirely just gets you the black bar with no flickering. Real XFB fixes the issue, IIRC, but I'm not 100% sure (and fuck if I care enough to copy it over the network to test). If that's right, the game probably doesn't default to Real XFB due to its performance cost adding to the game's already-shitty performance.

Well, in my testing, Real XFB just caused the game to crash shortly after loading up a save file.

Real XFB causes Dolphin to give multiple errors and crash with dual core enabled. Disabling dual core fixes the black bar bug entirely, and makes real XFB work fine.

So basically, it is impossible for MP2 to have decent performance and glitch-free graphics at the same time.

Well, maybe not on current CPUs or current Dolphin, but that'll likely change in a year or two.

Tested comex's dc-netplay branch, the fifo code he introduced there fixes this issue for MP3, but unfortunately MP2 freezes just before emu render 3d

Dualcore Netplay isn't finished, if he finished it, it's very likely it'd fix the majority of issues in those games. Just to note, F-Zero GX also freezes before 3D. I've tested this before, but I only have Trilogy dumped, if you can be more specific on what's going on in 3, I'll gladly test it and figure out what's going on.

What do you mean "what's going on in 3?" if you mean MP3, just like i said it is going fine, even 3d rendering

Does it fix the black bar? I know there were flickering issues, but I was wondering about everything else that's commonplace in dualcore.

Thanks.

Blackbar does not apeear in MP3 even with PAL60 mode
BTW, MP Trilogy acts the same way, MP3 works fine, MP2 doesn't go 3d

Hm. Okay. MPTrilogy, NTSC, is instantly freezing in 4.0-652 of DC-netplay branch, so I can't test.

I'm using build 430, clearly fifo changes, cause latest DC netplay has some wii-remote connection issues for me

Besides it's instantly freezed for me too, but than it's all because i forgot to put DeterministicGPUSync = 1 in game ini, maybe youre too

Even using that build, I immediately freeze on the DC-netplay branch 4.0-430. Ah well. Hopefully Comex can be bothered to look into this and see if we can't get some form of it to work for more of the games that are afflicted by this.

Oh, that actually did it. Thanks. Going to see how this fairs on NTSC. I never even knew it had that feature lol.

Prime 3 (NTSC) does not even boot without Sync GPU in dc-netplay, which neuters most of the speed gains of using dual core, which is the only reason to use it at all.

Should be fised by this
https://github.com/magumagu/dolphin/commit/ee5122e7bf29d39b84ede3c63fd543381fa86851#commitcomment-6515786
please cinfirm

Can confirm, but causes issues and slowdowns in other games, unfortunately. Would need to be an option. A lot of games, including Metroid Prime 2/3/trilogy get no slowdown, but all the benefits.

It is already ini optional, but even if option is disabled Metroids still work properly, on a new code

https://github.com/magumagu/dolphin/commit/809e41edc7fad9b720fea6bd948249ee4039d6cd
New code which runs a lot smother, no even feeling of loading periods

This type of code scares me. Mertroid only has fifo reset. I can back to the road and fix this in a few days. I will do that, only for explain the real problem.

I wasn't planning to submit that to master... it was mostly just an experiment to figure out why dc-netplay helped this issue. That said, if you have a better explanation of what's going wrong than just "the game crashes when the GPU thread isn't reading data from the fifo quickly enough", that would be useful.

Maybe this one should be fixed by ini change

Maybe this one should be fixed by ini change. mmm Shader compilation problem and others thing producing time out fixed by fifo hack sound ugly. This issue should be here and we should be change the description to. Games time outs producing, fifo resets and slowdowns, commonly that is produce by sahder compilation.

Issue 8229 has been merged into this issue.

Works really nice with this
https://github.com/dolphin-emu/dolphin/pull/2533

Possibly fixed without SyncGPU here? Testing needed: https://github.com/dolphin-emu/dolphin/pull/2686

Tested more, only black bar is fixed by this PR, the screen is still blinks sometimes, and there are still sahder caching glithes when screen blinks, SyncGpu is the best way for now

PR 2686 was merged in 4.0-7517. https://dolphin-emu.org/download/dev/ecbb83fa0f6c63def7b0e7d17b6f7e8b47bcb724/