Atelier Iris 2/3 + MTGS

[GoogleCodeExporter]

With both Atelier Iris 2 and 3 (US), there's some strange behaviour
sometimes, where what just happened (half a second) would happen again. For
example, it's possible that when entering a shop and talking to the seller,
one'd see the whole entering the shop, walking to the seller and starting
the conversation again.

It's normally just a hiccup, but it gets stuck in an infinite loop every
2-6h of gameplay. Seems to happen more often in iris 3.

Disabling MTGS kills the issue completely. Sadly, Iris 3 memcard save
doesn't work and disabling MTGS and loading my state (15h into the game)
means black instead of transparent backgrounds in many scenarios (it
doesn't seem to fix itself by doing anything, either. Played about 10h like
this).

--------------------------------------

1) Did the game ever work correctly (i.e. not have this problem) on the
Official PCSX2 build or an earlier version of PCSX2 playground? 
(If so, please specify the latest pcsx2-playground or Official revision
that last worked.)

No, thought I played through the whole Iris 2 just this week.

2) What steps will reproduce the problem?
1. Enable MTGS
2. Play for a while
3. Curse the world

4) What version of the product are you using? On what operating system?
r551, vista64 SP1, e2160@3.25, ati HD4850.

Original issue reported on code.google.com by valles...@gmail.com on 5 Jan 2009 at 9:13

[GoogleCodeExporter]

As an added note, ESC doesn't work on this hangs. One has to kill the process.

Original comment by valles...@gmail.com on 8 Jan 2009 at 4:49

[GoogleCodeExporter]

That's a very odd problem and not one that's been noticed by anyone else who's 
tried
to reproduce it.  All your problems are definitely related to MTGS thread 
management.
In the case of the loopy scenes, what's happening is that the MTGS replays it's
ringbuffer (which can hod several frames of content) while the PS2 emulation 
part of
Pcsx2 apparently stalls.  The same thing with the crash at startup -- the MTGS
somehow fails to init, or maybe it initializes fine but fails to notify Pcsx2.  
Esc
hanging is the same deal, since it must wait on the MTGS to tell it when the GS 
is done.

Anyways, these are all *very* basic functions of the MTGS thread, and use 
built-in
features of the CPU to synchronize the threads.  It's rather disturbing that 
they can
work sometimes for you fine, but not other times.  Have you been having any 
other
sort of strange behavior with your computer?  Unfortunately most current-day 
uses of
multithreading doesn't really require much synchronization, so even if your PC 
is
malfunctioning it may only become obvious in an app like Pcsx2.

I'm going to have to label this as a potential local hardware issue, unless 
someone
else can reproduce these odd behaviors.

Original comment by Jake.Stine on 8 Jan 2009 at 3:36

[GoogleCodeExporter]

No, no problems at all with other apps.

The machine has been on 24/7 and stable as a rock in this setup for half a year,
being not just apparently stable, but stable enough to pass memtest86, compile 
gentoo
a few times over (without ever seeing any non-reproduceable internal compiler 
error),
convert movies, compress DVD images with 7z, play crysis and other stressful 
tasks.

I've also been using pcsx2 just fine for a while (played whole Final Fantasy X, 
Ar
Tonelico 1 and Atelier Iris Eternal Mana without a problem, just a few weeks 
ago. AT1
and Iris1 would sometimes be laggy vs input, specially when doing some 
webbrowsing
without stopping pcsx, and then resuming, only to be fixed by entering and 
leaving
the in-game "status" screen... but never hiccup or crash).

Whatever it is, it must have been introduced recently. Sadly, hiccups and then 
hangs
only happen after a few hours playing (I'm guessing it'd also affect these 
games I've
already completed, but since I'm not replaying those knowing so will be hard.)

My guess so far is that MTGS can't recover from one thread getting too desynced 
from
the other. Maybe it could be reproduced by stopping the process of a thread for 
a few
seconds and then resuming it? I have no idea. I seriously hope people start to
reproduce the problem soon. Maybe it'll affect Ar Tonelico 2, with uses the same
engine all these games use, and which US release is due this month and I expect 
a few
people to play with pcsx2-pg :).

Original comment by valles...@gmail.com on 8 Jan 2009 at 8:31

[GoogleCodeExporter]

None of the tasks you mentioned require thread synchronization, and that's the
problem: the type of thread synchronization being used by pcsx2 is something 
very few
programs have to use.  I can't even name for you another app that relies on 
it-- I
don't know of any offhand.  Additionally it could be related to your video card 
or
video drivers, in which case none of the aforementioned programs would be 
dependent
on those either.

What concerns me most here is that no one else has reported MTGS hanging on 
startup,
and is a pretty serious bug that should be easy to reproduce (but it's not
reproducing).  Furthermore, it's some of the simplest synchronization code in 
the
MTGS so it's not like there's much room for non-obvious errors.  If it works on 
one
dual-core machine it should most certainly work on them all.

As for older versions of Pcsx2, they did use a different version of thread
synchronization, which I call an "aggressive" spin-wait loop, which was 
generally
slower and very un-friendly to HT machines, operating system kernels, L2 caches 
in
particular.  Aggressive spin-waits are the most common type of thread 
synchronization
because of their logical simplicity, but aren't really ideal.  Pcsx2's new 
method is
faster and also much more stable (except in your case.. -_-), and it's also the
required approach if we want to expand the emu to use more threads in the 
future.

>> Sadly, hiccups and then hangs only happen after a few hours playing (I'm 
guessing
it'd also affect these games I've already completed, but since I'm not replaying
those knowing so will be hard.)

This is yet more evidence that something seems wrong with your computer.  The 
MTGS is
a *very* active portion of pcsx2.  Under normal circumstances it's processing
hundreds of megabytes of data per second, all through a relatively small 3MB 
ring
buffer.  It uses highly optimized 'implied' pointer references, which means it's
incredibly sensitive to even the smallest amount of desynching -- as in the 1/2
second feedloop in the case where GIFtag data being sent isn't state-dependent, 
and a
fairly immediate crash if the GIFtag data is state-dependent.  The entire state 
of
the MTGS is effectively invalid until the read-position loops all the way back
through the ringbuffer and re-syncs with the write position.

That's what happens if it desyncs by even one byte. ;)

So the question is: how comes it only starts happening after a couple hours? So 
the
first few hundred *terrabytes* of transferred data are fine, and suddenly it 
lapses
by a single byte.  Joy.  Furthermore, how does the basic initialization 
procedure,
which works flawlessly for 99% of the users out there, consistently fail?

I'm leaving this open in case someone else can reproduce the problem or come up 
with
some ideas.

Original comment by Jake.Stine on 9 Jan 2009 at 12:26

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I don't understand your references to "MTGS hanging on startup". What do you 
mean
there? I never reported that.

As to everything else... I sure hope somebody else reports the same issue.

I'll add whatever relevant information I have, like it not happening with other 
games
once I get to playing those and such.

>>>So the question is: how comes it only starts happening after a couple hours?

On average, it happens twice per full day spent playing iris2 or iris3, but 
might
happen after just a few minutes.

Original comment by valles...@gmail.com on 9 Jan 2009 at 1:03

[GoogleCodeExporter]

Ah crap, I'm getting issues mixed up.
This is what happens when people put things like "p.s. btw something else 
entirely
unrelated!" stuff in their reports like the guy in Issue 110 did. -_-

Original comment by Jake.Stine on 9 Jan 2009 at 2:19

[GoogleCodeExporter]

Do you run with frameskipping modes enabled or disabled normally?

Original comment by Jake.Stine on 9 Jan 2009 at 5:04

[GoogleCodeExporter]

I use "limit". All the manual settings to 0, screen runs at 60fps.

Original comment by valles...@gmail.com on 9 Jan 2009 at 6:11

[GoogleCodeExporter]

I think I have this bug fixed, as of r585.  I know it's not an easy thing to 
test
for.  To "improve" the chance of crashing, visit primarily scenes that cause 
that
input lagginess, and use Gsdx software mode to slooooow down your fps.  The 
slower
your fps and the more input lag you get, the more likely you'll hit the right
condition where the read/write positions slip up.

The lagginess of input, btw, is not a bug but a "feature" of MTGS in a sense --
that's what happens when the MTGS gets a lot of frames of data queued up.  It 
means
the queue is working well!  Perhaps too well. :D  It's fixable but low priority 
since
it only affects a couple scenes in a couple games, and the fix could cause more
instabilities or something. >_<

Original comment by Jake.Stine on 13 Jan 2009 at 4:05

[GoogleCodeExporter]

Ok, I'm going to build >r585 and continue playing, and report if it crashes 
again or
if I play a whole day without crashing. (I was playing last night and had a 
crash
every 2-3h).

However, since I've got some university exams this saturday, I might not be 
able to
trigger it till later.

Even if we later discover this bugfix doesn't fix the bug, at the very least you
found something wrong and fixed it :)

Original comment by valles...@gmail.com on 13 Jan 2009 at 11:28

[GoogleCodeExporter]

Spent the day playing (instead of preparing some exam, which I'll do now or 
else...).
There hasn't been a single crash, in a time span where I'd have easily suffered 
3-5.

This can happily be marked as fixed, hopefully forever.

Original comment by valles...@gmail.com on 15 Jan 2009 at 1:46

[GoogleCodeExporter]

closing this issue since vallesroc says its fixed

Original comment by cottonvibes on 19 Jan 2009 at 7:49

• Changed state: Fixed