Emulator

Update SVN and you wont see CommandProcessor::GatherPipeBursted anymore.
Anyway it's a GPU general perf issue.

1016545 20.0904 anon (tgid:6337 range:0x419ba000-0x42aba000) Dolphin (no symbols)
981907 19.4059 libGLcore.so.177.82 Dolphin (no symbols)

If we can't have more verbose/deeper profiling infos on this, it pretty useless :p
If you/someone can't provide more I'll close this issue.

I'll try again later --- I'd also need to fix the crashes DEBUGFAST etc. :P

Further investigation as suggested by mb2 is blocked by issue 487.

Essentially converted __Log to vprintf, so I can still have a go at this. Profiling
with r1878, -DDEBUGFAST -g -O3, Dual Core and Safe texture cache enabled. Profiling a
pure slow scene from the intro, when the frigate itself is almost fully visible.

CPU: AMD64 processors, speed 2210.05 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of
0x00 (No unit mask) count 100000
samples % image name app name symbol name
524365 33.0901 anon (tgid:14251 range:0x40eca000-0x41fca000) Dolphin
(no symbols)
163628 10.3257 libGLcore.so.177.82 Dolphin (no symbols)
85232 5.3786 Dolphin Dolphin
Memory::GetPointer(unsigned int)
78796 4.9724 no-vmlinux no-vmlinux (no symbols)
61344 3.8711 anon (tgid:14251 range:0x40e82000-0x40e84000) Dolphin
(no symbols)
43002 2.7136 libPlugin_VideoOGL.so Dolphin
Memory_Read_U32(unsigned int)
37778 2.3840 libPlugin_VideoOGL.so Dolphin
VertexLoader::RunVertices(int, int, int)
35692 2.2523 libPlugin_VideoOGL.so Dolphin
TexCoord_ReadIndex16_Float2()
26253 1.6567 Dolphin Dolphin
Interpreter::divwux(UGeckoInstruction)
26217 1.6544 libc-2.7.so Dolphin memcpy
25255 1.5937 libPlugin_VideoOGL.so Dolphin
Common::swap32(unsigned int)
19556 1.2341 Dolphin Dolphin
Memory::Write_U32(unsigned int, unsigned int)
18892 1.1922 Dolphin Dolphin
GPFifo::Write32(unsigned int, unsigned int)
16604 1.0478 Dolphin Dolphin
Common::swap32(unsigned int)
15652 0.9877 libPlugin_VideoOGL.so Dolphin
Pos_ReadIndex16_Float()
14942 0.9429 libPlugin_VideoOGL.so Dolphin DataReadU16()
13504 0.8522 Dolphin Dolphin
GPFifo::CheckGatherPipe()
13271 0.8375 libPlugin_VideoOGL.so Dolphin
Common::swap16(unsigned short)
12536 0.7911 libGL.so.177.82 Dolphin (no symbols)
11389 0.7187 oprofiled oprofiled (no symbols)
10044 0.6338 libpthread-2.7.so Dolphin pthread_mutex_lock
9713 0.6129 libPlugin_VideoOGL.so Dolphin
Memory_Read_U16(unsigned int)
8747 0.5520 libPlugin_VideoOGL.so Dolphin
VertexLoader_Normal::Normal_Index16_Float()
8466 0.5342 Dolphin Dolphin
Interpreter::bclrx(UGeckoInstruction)
8430 0.5320 Dolphin Dolphin
Interpreter::fcmpo(UGeckoInstruction)
8407 0.5305 libPlugin_VideoOGL.so Dolphin
TexCoord_ReadIndex16_UShort2()
7939 0.5010 libPlugin_VideoOGL.so Dolphin
VertexManager::Flush()

My system should be well capable of showing scenes with high poly count, by the way ;)

Blargh, same result :P

Is there any way I can profile the JIT output itself, to see wether it gets 'stuck'
at some points? Maybe something that can get the instruction pointer once every
seconds, so I can analyse the 'code usage intensity'? ;)

take a chance on this issue again. you seem to be a "report and forget" type of person :)

More like FTBFS and busybusybusybusy.

FTBFS is linux-speak for "i'm a laz0r"
:D

I've spent some time looking at Metroid Prime recently; some observations:

1. I'm not entirely sure why (I haven't profiled regular Jit builds for this game),
   but JitIL is a lot faster than the regular Jit, at least in some places, so I'd
   suggest trying that.

2. If you see Common::swap16 in a profile, you're not using an optimized build.

3. If by the "intro cinematic" you mean the scene just before you gain control, the
   issue is a graphics plugin slowdown.

1. Will try.
2. I don't get it then...
3. That's exactly what I meant (and expected, as well).

2. you're not using debugfast/release

2. Strange, I was using prof, which had -O3 -g at that time...

Disable STC and whatch the intro fly if it doesn't crash.

This is due to bad hardware that's all :p
MP1 intro movie runs +90 fps here, STC doesn't seem to change anything, maybe you can
optimize it a bit..
Also, the linux build is slower than the windows one, maybe we can try to 'fix' that

Still an issue???

The intro (Alas, the game as well for most part) runs extremely slow as well, and
audio gets desynched

Running on Vista x64

Safe Texture Cache or not, the performance is the same. Without STC there are
constant crashes (As expected)

What are we going to do on this one... ?

I say it's not really important. Accurate emulation > fast emulation

actually it's not even at that slow at all here :p

These days, if it's slow on this specific scene it's just because of the sheer amount
of geometry being processed. the MP games tend to render waaay more geometry than
really needed, but hey, that's not our fault :P

Merge with another "caching vertices is cool"/whatever issue.

Please respond if this issue is still valid, or it will be closed.

I think I'll try it again this Saturday (at least on Win7, perhaps also on Debian). The hardware has changed a bit, though ;)