Project

General

Profile

Actions

Emulator Issues #4336

closed

Metroid Prime Games FIFO Regressions (revs 6554 and 7185)

Added by SpiderTECH611 over 13 years ago. Updated over 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
GFX
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What steps will reproduce the problem?

  1. Start game
  2. Sometimes it starts at the warning screen but also always in game

What is the expected output?
What do you see instead? Major flickering. If I had Epilepsy I wouldn't be typing this right now.

Dolphin version with the problem? Other Dolphin version without the
problem? Not sure how far back this goes its been a while since it started, maybe just before the 7000 series of revs. Will test old revs if need be, but Latest rev has it.

32-bit or 64-bit and any other build parameters? Only really tested 64

OS version and versions of tools/libraries used?Win7 x64

Please provide any additional information below.

Settings:
-Graphics: Stock Game properties

-Config:

--General:
---Dual Core ON
---Idle Skip ON
---Frame limit 60 no FPS for Limiting
---Skip GC Bios
---CPU Jit (Testing with JITIL results in the same)
---Thread Lock Off
---DSP LLE Thread OFF

--Display
---Dx9/11/OGL
---any resolution
---Progressive ON

Quad Core Q6700 @ 2.66
4GB Ram
Nvidia 8800GTS 512
all drivers are up to date


Related issues 3 (0 open3 closed)

Has duplicate Emulator - Emulator Issues #5185: Metroid Prime 2 and others games with black bars after some lags (DX9,DX11 and OPENGL)Duplicate

Actions
Has duplicate Emulator - Emulator Issues #5448: Flickering in Metroid Prime 2Duplicate

Actions
Has duplicate Emulator - Emulator Issues #8229: Shader compiler error in OpenGL for Metroid Prime 2: EchoesDuplicate

Actions
Actions #1

Updated by SpiderTECH611 over 13 years ago

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.

Actions #2

Updated by NaturalViolence over 13 years ago

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

Actions #3

Updated by NaturalViolence over 13 years ago

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

I don't experience this issue.

Actions #4

Updated by DimitriPilot3 over 13 years ago

  • Category set to gfx
Actions #5

Updated by marcosvitali over 13 years ago

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

Actions #6

Updated by hatarumoroboshi over 13 years ago

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

Actions #7

Updated by SpiderTECH611 over 13 years ago

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.

Actions #8

Updated by marcosvitali over 13 years ago

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

Actions #9

Updated by hatarumoroboshi over 13 years ago

My frames are ok...

Actions #10

Updated by SpiderTECH611 over 13 years ago

@ &

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.

Actions #11

Updated by hatarumoroboshi over 13 years ago

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.

Actions #12

Updated by SpiderTECH611 over 13 years ago

@

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.

Actions #13

Updated by hatarumoroboshi over 13 years ago

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.

Actions #14

Updated by SpiderTECH611 over 13 years ago

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

, 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.

Actions #15

Updated by hatarumoroboshi over 13 years ago

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

Actions #16

Updated by Autoran1 almost 13 years ago

This issue is similar to issue 3902
caused by r6554

Actions #17

Updated by Autoran1 almost 13 years ago

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

Actions #18

Updated by Autoran1 almost 13 years ago

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

Actions #19

Updated by marcosvitali almost 13 years ago

  • Status changed from New to Questionable

Well, so you can close this issue too. because is not a bug. The games is Aborting frames. When the game detect perfomance problem AbortFrames = FifoReset. In teh real HW that is smooth but dolphin is an emulator.

Actions #20

Updated by Autoran1 almost 13 years ago

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

Actions #21

Updated by marcosvitali almost 13 years ago

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.

Actions #22

Updated by Autoran1 almost 13 years ago

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

Actions #23

Updated by Autoran1 almost 13 years ago

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

Actions #24

Updated by Autoran1 almost 13 years ago

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

Actions #25

Updated by marcosvitali almost 13 years ago

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.

Actions #26

Updated by Autoran1 almost 13 years ago

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 :)

Actions #28

Updated by Autoran1 almost 12 years ago

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

Actions #29

Updated by Autoran1 almost 12 years ago

Issue 5185 has been merged into this issue.

Actions #30

Updated by Autoran1 almost 12 years ago

Issue 5431 has been merged into this issue.

Actions #31

Updated by Autoran1 almost 12 years ago

Issue 5448 has been merged into this issue.

Actions #32

Updated by Autoran1 almost 12 years ago

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

Actions #33

Updated by rachelbryk almost 12 years ago

5431 is not even remotely similar to this.

Actions #34

Updated by Autoran1 almost 12 years ago

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

Actions #35

Updated by skidau almost 12 years ago

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.

Actions #36

Updated by skidau almost 12 years ago

  • Status changed from Questionable to Fixed

Fixed by r0e2c3f3483e2.

Actions #37

Updated by MayImilae almost 12 years ago

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.

Actions #38

Updated by Autoran1 almost 12 years ago

  • Status changed from Fixed to Questionable

Not fixed, Metroid 1 & 2 have black screen and sound with SyncGPU option and it's slow like hell
revert to previous status

Actions #39

Updated by MayImilae almost 12 years ago

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.

Actions #40

Updated by MayImilae almost 12 years ago

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.

Actions #41

Updated by MayImilae almost 12 years ago

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.

Actions #42

Updated by MayImilae almost 12 years ago

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

Actions #43

Updated by skidau almost 12 years ago

  • Status changed from Questionable to Fixed

This issue was closed by revision 0399959c3901.

Actions #44

Updated by Autoran1 almost 12 years ago

  • Status changed from Fixed to Accepted

Sorry to say it but everything is the same

Actions #45

Updated by MayImilae almost 12 years ago

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

Actions #46

Updated by Autoran1 almost 12 years ago

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

Actions #47

Updated by Autoran1 almost 12 years ago

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

Actions #48

Updated by Autoran1 almost 12 years ago

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

Actions #49

Updated by MayImilae almost 12 years ago

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.

Actions #50

Updated by Autoran1 almost 12 years ago

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

Actions #51

Updated by MayImilae almost 12 years ago

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.

Actions #52

Updated by Autoran1 almost 12 years ago

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

Actions #53

Updated by Autoran1 almost 12 years ago

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

Actions #54

Updated by skidau almost 12 years ago

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

Actions #55

Updated by MayImilae almost 12 years ago

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.

Actions #56

Updated by MayImilae almost 12 years ago

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-

Actions #57

Updated by Autoran1 almost 12 years ago

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

Actions #58

Updated by MayImilae almost 12 years ago

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

Actions #59

Updated by Billiard26 over 11 years ago

  • Issue type set to Bug
Actions #60

Updated by autofire372 almost 11 years ago

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?

Actions #61

Updated by Bearborg almost 11 years ago

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

Actions #62

Updated by autofire372 almost 11 years ago

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

Actions #63

Updated by Bearborg almost 11 years ago

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.

Actions #64

Updated by autofire372 almost 11 years ago

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?

Actions #65

Updated by pauldacheez almost 11 years ago

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.

Actions #66

Updated by autofire372 almost 11 years ago

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

Actions #67

Updated by Bearborg almost 11 years ago

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.

Actions #68

Updated by autofire372 almost 11 years ago

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

Actions #69

Updated by pauldacheez almost 11 years ago

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

Actions #70

Updated by Autoran1 almost 11 years ago

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

Actions #71

Updated by JMC4789 almost 11 years ago

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.

Actions #72

Updated by Autoran1 almost 11 years ago

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

Actions #73

Updated by JMC4789 almost 11 years ago

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.

Actions #74

Updated by Autoran1 almost 11 years ago

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

Actions #75

Updated by JMC4789 almost 11 years ago

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

Actions #76

Updated by Autoran1 almost 11 years ago

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

Actions #77

Updated by Autoran1 almost 11 years ago

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

Actions #78

Updated by JMC4789 almost 11 years ago

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.

Actions #79

Updated by JMC4789 almost 11 years ago

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

Actions #80

Updated by autofire372 almost 11 years ago

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.

Actions #82

Updated by JMC4789 over 10 years ago

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.

Actions #83

Updated by Autoran1 over 10 years ago

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

Actions #84

Updated by Autoran1 over 10 years ago

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

Actions #85

Updated by marcosvitali over 10 years ago

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.

Actions #86

Updated by magumagu9 over 10 years ago

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.

Actions #87

Updated by Autoran1 about 10 years ago

Maybe this one should be fixed by ini change

Actions #88

Updated by marcosvitali about 10 years ago

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.

Actions #89

Updated by JMC4789 almost 10 years ago

Issue 8229 has been merged into this issue.

Actions #90

Updated by Autoran1 over 9 years ago

Actions #91

Updated by JMC4789 over 9 years ago

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

Actions #92

Updated by JMC4789 over 9 years ago

  • Status changed from Accepted to Fix pending

Confirmed to be fixed in Virtual and RealXFB. Triggered the glitch, then turned on XFB and it was no longer broken. Fixed in Pull Request 2686

https://github.com/dolphin-emu/dolphin/pull/2686

Actions #93

Updated by Autoran1 over 9 years ago

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

Actions #95

Updated by JosJuice over 9 years ago

  • Status changed from Fix pending to Fixed
Actions

Also available in: Atom PDF