Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix some more GPU thread sync issues #3120

Merged
merged 7 commits into from Aug 11, 2013

Conversation

Projects
None yet
4 participants
@unknownbrackets
Copy link
Collaborator

commented Aug 11, 2013

Mostly I was trying to hunt for a very random and hard to repro hang I'm getting in Tales of Phantasia X. I'm not sure if I got it...

Anyway, this fixes a problem with the dirty FB check skipping way too many frames, since it didn't give the GE time to finish. Should not hurt performance, and fixes at least God Eater Burst.

Could maybe fix Virtua Tennis too.

-[Unknown]

unknownbrackets added some commits Aug 10, 2013

Avoid a possible thread sync issue.
Could be that it's about to wake listsync, does, and then we wait.
SyncThread before deciding if the fbo is dirty.
Fixes fps drops in yet other games with multithreading enabled.
@solarmystic

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2013

Also fixes GE timing in the following games when MT is enabled (#3116 (comment)) :-

Monster Hunter Freedom Unite
Monster Hunter Portable 3rd HD
Project Diva 2nd (retracted, see the comment below for an explanation #3120 (comment))

unknownbrackets added some commits Aug 11, 2013

Use a possibly harmless hack to prevent hangs.
Not sure where the problem is, but this fixes it pretty consistently for
me... seems like lists are somehow not being processed after becoming
processable?
@unknownbrackets

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 11, 2013

Added a bit of a hack to workaround the issue where somehow, display lists are being left unprocessed. For me it is rare, and processing lists on a sync doesn't even seem necessarily wrong. It's not really a fix, though, but it does make it recover.

Let's see if I can find what I broke in God of War. Hmm... demo works... maybe/probably this helped it too.

-[Unknown]

@solarmystic

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2013

@unknownbrackets

I have to retract my previous statement about Project Diva 2nd being fixed by this series of commits, because apparently it still isn't, even after all the commits have been manually merged.

Internal FPS is still abysmal at the character screen (9-15) and is pretty much unplayable with MT on, since it's very stuttery. Also, leaving it to idle at the said character screen leads to a frenzy of Speed/FPS changes and then, a crash.

Results for the Monhun games and Gods eater burst still holds true.

These commits are still good to go, it seems like Project Diva 2nd has its own class of issues with MT. #3116 (comment)

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 11, 2013

My guess is that that game has an issue with never syncing lists/draws and not being happy with them essentially taking until the end of the frame. The best idea I have to fix it is:

  1. Limit the downcount in the GE runloop by X instructions.
    1.1. Every time downcount hits 0, expose the current estimated tick offset.
  2. On the CPU side, schedule an event every Y cycles.
    2.1. When this event trips, check the current GE estimated tick offset.
    2.2. If it's too far behind (more than Z cycles), either SyncThread() or delay/something to let it catch up.

This seems a bit complicated but maybe not horrible. X would be probably easy to tune, and Y could be 370,000 (1/10th a frame), but Z will probably be harder to tune properly. Or maybe Z would be 0.

-[Unknown]

@hrydgard

This comment has been minimized.

Copy link
Owner

commented Aug 11, 2013

Capped waits are usually a code smell, because you get a different "state" afterwards if it hits than if it doesn't, which may be hard to reason about. In this case I don't think it's that bad though..

@hrydgard

This comment has been minimized.

Copy link
Owner

commented Aug 11, 2013

I think your idea with exposing and looking at the tick offset sounds very reasonable.

hrydgard added a commit that referenced this pull request Aug 11, 2013

Merge pull request #3120 from unknownbrackets/gpu-thread
Fix some more GPU thread sync issues

@hrydgard hrydgard merged commit c709315 into hrydgard:master Aug 11, 2013

@unknownbrackets

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 11, 2013

I agree about capped waits, but since win32 xp doesn't do locking atomically on condition variables, it's definitely possible an event might slip through the cracks. It's also sorta safer in this case.

-[Unknown]

@unknownbrackets unknownbrackets deleted the unknownbrackets:gpu-thread branch Aug 11, 2013

@Lazor999

This comment has been minimized.

Copy link

commented Nov 28, 2016

Do i need to be here for help?

My dangan tonpa isn't working, crash on startup, ios 5S. Read through the steps but doesn't work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.