Project

General

Profile

Actions

Emulator Issues #1085

closed

Sychronization taking a lot of time in profile

Added by magumagu9 almost 15 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
% 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

Top of an oprofile run for the Animal Crossing title screen:

109108 15.7371 fglrx_dri.so fglrx_dri.so /usr/lib/dri/fglrx_dri.so
101322 14.6141 no-vmlinux no-vmlinux /no-vmlinux
47874 6.9050 libpthread-2.8.90.so libpthread-2.8.90.so pthread_mutex_lock
41144 5.9344 libpthread-2.8.90.so libpthread-2.8.90.so
__pthread_mutex_unlock_usercnt
22604 3.2603 libPlugin_VideoOGL.so libPlugin_VideoOGL.so
Fifo_EnterLoop(SVideoInitialize const&)
19646 2.8336 libc-2.8.90.so libc-2.8.90.so memcpy
12547 1.8097 libpulsecore.so.5.0.1 libpulsecore.so.5.0.1 /usr/lib/libpulsecore.so.5.0.1
12481 1.8002 libPlugin_VideoOGL.so libPlugin_VideoOGL.so
Common::CriticalSection::Leave()
11860 1.7106 libPlugin_VideoOGL.so libPlugin_VideoOGL.so
Common::CriticalSection::Enter()
10557 1.5227 Dolphin Dolphin Interpreter::psq_l(UGeckoInstruction)
7498 1.0815 Dolphin Dolphin MemChecks::GetMemCheck(unsigned
int)
6722 0.9695 Dolphin Dolphin void
Memory::WriteToHardware<unsigned int>(unsigned int, unsigned int, unsigned int,
Memory::XCheckTLBFlag)
6315 0.9108 Dolphin Dolphin
CommandProcessor::GatherPipeBursted()
6014 0.8674 Dolphin Dolphin Memory::Write_U32(unsigned int,
unsigned int)
5636 0.8129 libPlugin_VideoOGL.so libPlugin_VideoOGL.so __i686.get_pc_thunk.bx
4628 0.6675 Dolphin Dolphin GPFifo::Write32(unsigned int,
unsigned int)
4544 0.6554 libpixman-1.so.0.12.0 libpixman-1.so.0.12.0
/usr/lib/libpixman-1.so.0.12.0
4056 0.5850 libpulse.so.0.4.1 libpulse.so.0.4.1 /usr/lib/libpulse.so.0.4.1
3896 0.5619 libPlugin_VideoOGL.so libPlugin_VideoOGL.so
Common::SyncInterlockedExchange(int*, int)

We're spending a lot of time acquiring locks, which isn't good. Relevant functions:
pthread_mutex_lock, __pthread_mutex_unlock_usercnt, CriticalSection::Enter,
CriticalSection::Leave, Common::SyncInterlockedExchange. Over 15% of the samples are in
locking functions. (The screen in question runs at approximately 40/60fps on my computer.)

Actions #1

Updated by federelli almost 15 years ago

Runs full speed on my machine, how can i turn the profiler on? Really interested!

Actions #2

Updated by magumagu9 almost 15 years ago

My machine is a laptop, and a few years old, so it's not surprising it runs at full
speed on other computers.

The profiler is just http://oprofile.sourceforge.net/ ; works best with a build using
flavor=prof. (Linux required.)

Actions #3

Updated by memberTwo.mb2 almost 15 years ago

Well, not too surprising, I saw that "s_criticalFifo.Enter()" is back in fifo.cpp.
Sure it's the easy safe way to sync but mutexes are way to slow for the contention
required by this CPU/GP communication... IMHO.
Anyway, I guess it's less an issue for windows users who have "real" critical sections.
Maybe you could just spin or sleep if GPFifoRWDistance value is too low... Until
someone put is nose in interlocked sync stuff and , again, get rid of these mutexes :p

BTW, does the use of this "critical section" fix some DC sync weirdness we had?

Actions #4

Updated by magumagu9 almost 15 years ago

BTW, does the use of this "critical section" fix some DC sync weirdness we had?

Dunno; the only semi-consistent weirdness I've ever run into with DC is that it doesn't play well with
savestates, and I don't think that has been fixed recently.

Doing some more profiling, this also shows up on the demo video in Twilight Princess.

Actions #5

Updated by nakeee over 14 years ago

  • Status changed from New to Invalid

It was changed like 3 times since this bug.
And no one seems to look at it.
Closing for now.

Actions

Also available in: Atom PDF