Hatsune Miku Dreamy Theater 2nd\Extend slowdown issue

[Nezarn]

Game never runs at 60 fps, and occasionally has slowdowns to 40 and 30 fps.

And according to @kd-11 its not an OGL\Vulkan issue (can't test DX12 because vertex texture support).

PS.: Theres a bottleneck somewhere, even when using LLVM, cpu usage is so low that my cpu (i5-4690k) doesn't even run at full turboboost speed.

Maybe some kinda threading issue? (this is my hint, since when using LLVM, in Dreamy Theater 2nd sound gets stutter)

[Waelwindows]

There are some scenes that run at 60 FPS, usually these scenes don't have the character drawn e.g. the beginning of Gekishou

[RainKikyou]

6700K oc to 4.5GHZ and use llvm, extend can be basically stable 60fps.The clock of the high point is indeed very high，but the price a bit too high

[Waelwindows]

LLVM still doesn't work in skylake, and im alittle bit afraid of ocing my cpu since im a beginner at it

[Nezarn]

@RainKikyou im sure that doesn't really fix the problem, since with LLVM, cpu usage is so low, it doesn't need higher frequency. (and when i hit 60 fps in game in certain places, my cpu downclocks with LLVM)

[RaulDJ]

Furthermore, according to the time needed to render each frame, we're almost never getting even the maximum frame rate:

http://i.imgur.com/TEszdd2.png

Core i5 4670k running at 4.4GHz, ~33% Total CPU usage by the emulator.

3ms + 8.8ms + 1.2ms + 4.2ms = 17ms ; so 1000 / 17 = 58.82 FPS ; I'm getting 47.49 FPS on the screenshot

[kd-11]

According to #2200 I should use steady_clock for more accurate measurement, although as I noted elsewhere, we lose several milliseconds somewhere and its not accounted for. Higher framerates are more sensitive to timing inconsistencies, so at 30fps it might not have been noticeable, but since this game targets 60, it becomes visible.

[Nezarn]

@kd-11 by the looks of it, Virtua Fighter 5 has the same issue: https://www.youtube.com/watch?v=CD4woIckkm4 (and if i remember right, theres a possibility it uses the same engine as Dreamy Theater games, since file\dir structure is nearly the same + had the same inverted color issue)

[Waelwindows]

@Nezarn Both game do use the same engine, Sega stated that in an interview. Even the DT models were modeled after the VF5 models. it's really evident. both games even share the same model format and graphical effects

[Nezarn]

@kd-11 another interesting fact is that if im on the song list i get 30ish FPS, but if i change to playlist, or edit (they have nearly 0 stuff listed), i get 60 fps (even on PPU interpreter).

Here's how FPS differs:

Main Menu 56-60FPS:

Song List ~34-36FPS:

Edit and Playlist 57-60FPS

In Dreamy Theater 2nd its more interesting, FPS is the same as in Extend...

But if you change the song list to Diva 1st, the FPS goes up a little, you gain up to 5+ FPS....

And theres only 2 difference, game doesn't say Achievement: 100% and these songs have 1 less difficulty. (also even if i change the clothing so its the same at the 2 songs, the fps is still as above on pics)

My guess is that whatever the game uses to render the difficulty\achievement 100%, theres the bottleneck, since as you can see above, when they aren't on screen, FPS is ~60 even on interpreter PPU.

TL;DR: i don't think this is a timing issue.

[RaulDJ]

I think it's "just" related to how much crap is on the screen and how big is the song list:

DIVA 2nd, biggest song list, ~43 FPS: http://i.imgur.com/xQwf1FZ.png
DIVA 1st, song list smaller than the DIVA 2nd one, ~48 FPS: http://i.imgur.com/B1XHkTT.png
DIVA DLC, no song list, ~60 FPS: http://i.imgur.com/yQa4LoN.png

[Nezarn]

@RaulDJ still that shouldn't affect speed in any way. (since it doesn't affect speed on a PS3), and its similiar to the slowdown at ingame. (since ingame it gets to 30-40ish fps)

[RaulDJ]

@Nezarn Well, the real hardware runs this always at 60 FPS, so I don't understand what you mean with "it doesn't affect speed on a PS3". Obviously if it can handle two or more character models at the same time at 60, it can handle simple menus too.

Anyway, being the "Achievement" text or the longer song list or whatever that causes the framerate go to shit, the thing is that we are loosing a lot of performance doing very basic 2D things, so yeah, it may affect the rhythm game part too.

[Nezarn]

@RaulDJ well my point is, i think the slowdown comes from rendering, and not from timing.

Also not just from 2D, but from lights\glow too, just check out "Just be friends" on Extend in Live mode

[RainKikyou]

Then I am curious, look this way, baby this song, extend only use llvm to achieve the same number of frames with 2nd
2nd：https://youtu.be/G0fMSwN08hg
extend（3:13）：https://youtu.be/N4o9_DJ9OhE

[Nezarn]

@kd-11 So i just ran rpcs3 in opengl and AMD GPU PerfStudio says this:

PS: for AMD PerfStudio capturing, you can't enable the legacy ogl buffers because then it fails, also another thing i noticed that RenderDoc overlay shows correct ms time, because i've done 1000/ ms and got the correct FPS

[RaulDJ]

@Nezarn

i think the slowdown comes from rendering, and not from timing

Yes, I would think that too but, in that case, why are we getting almost idle CPU and GPU usage?

The emulator is not reaching the 60 FPS target and even then the load on the chips is still low.

[kd-11]

Just to clarify:

1. Renderdoc time is literally the inverse of the fps. It doesnt matter if the renderer thread stalled or not; it is literally the time between frame begin and present and cannot help diagnose stalls within the renderer.
2. GPU Perfstudio analysis: It replays the API calls only, but the renderer thread does alot more than pure API calls. In fact in this case, being GPU limited means that without stalling elsewhere, as in if the renderer didnt have to perform extra tasks (e.g compiling shaders, generating index buffers to emulate primitives, waiting for the cpu threads to write to RSX fifo, etc) we'd have 57.73fps.

As I pointed out before, emulation speed as a whole regressed somewhere in the past few months and we added significant overhead per draw call. Testing this is easy, just run the fw_dice.ppu sample on builds from around july and compare with now. It is especially evident with vulkan and dx12. Opengl was affected too but recent optimizations have hidden this.

[Nezarn]

@kd-11 can you point me to a build that is faster than current? since i have a lot of free time (yay for not having a job i guess), i can track down which PR broke it.

NVM started testing

edit: I think I found it, in this PR FPS from ~40 goes down to 25 in dice sample (at least in DX12): #2112
OGL loses ~4 FPS, and Vulkan doesn't lose a lot either..(4-5 FPS) (i've mainly tested with DX12, because over time it always worked, while Vulkan doesn't work on old builds, and OGL was always kinda slow with dice sample...)

[kd-11]

The dice sample is an extreme case, pushing over 2000 draw calls with lots of tiny geometry; Its the kind of app that programmers intentionally avoid creating on PC due to how ineffeciently it utilizes the CPU-GPU relationship.

That said, I'm not sure vlj will revert the rewrite. I'm usually not for using runtime selected functions due to the performance penalties but thats the direction that was taken. The reason you probably didnt notice it in vulkan and opengl is because they are not as heavily optimized as DX12 anyway. By the way, OpenGL losing 4-5 fps is much worse than DX12 losing 15fps in terms of frametimes. On my system the drop was about 3 fps (12fps to 9fps) on OpenGL which is roughly 28 milliseconds per frame.

[Nezarn]

@kd-11 it looks like this isn't the only performance regression\issue, i've checked out master before that PR and manually modified it so Vertex Texture support would be in, and while it is a little bit better, still can't reach full speed on song selection menu and at certain effects (for example glowing stuff)game still slows down to ~35 FPS.... :( (tried both OGL and Vulkan)

[kd-11]

With these kinds of problems, every microsecond counts. To jump from 35 to 60 fps you need to gain back about 12 milliseconds which is quite a bit. The problem here is probably going to be in rsxthread implementation (even the base class; renderer agnostic) and will be difficult to work around/optimize especially due to lack of vertex buffer caching. Also, the game _might_ be using render targets in a manner that is hard for us to properly cache and predict, causing the emulator to create and destroy surfaces over and over, but I'd need confirmation here. We may also be spending too much time compiling/fetching programs for rendering. For each call, we gather the state, find the binary program in rsx memory, hash it and use the hash (and other attributes) to find an appropriate program in the cache. Often, we end up with the same program used the last draw call, adding unnecessary overhead that should've been avoided.

TL;DR This issue is probably going to take a while to fix. Time constraints and prioritizing functionality over performance are going to be the biggest hurdles here.

[RaulDJ]

@kd-11 So, because it will take a lot of time to get it fixed, could you at least please take a look at the render problems these games have? Maybe they're easier to get fixed and that would leave us with just the generic speed problem for them.

[Waelwindows]

There are only 3 graphical glitches AFAIK, one is the the models don't have self-shadowing which is clearly evident in the PS3 ver two is that there's flickering with black squares inside of the model's silhouette. The last one is when the skin is facing the light direction. it has weird behaviour.There's one animation glitch that's really present which is the model's animations are running in half of the speed, This happens in all DT games. (citation required)

[Nezarn]

@Waelwindows the slow animations are because the games doesn't run at 60 fps, animation is tied to framerate, if you're not at 60 or near 60, some scenes are even getting skipped

[RaulDJ]

@Nezarn @Waelwindows

Exactly, only camera movements, lip sync? and the gameplay itself it's independent of the framerate. Fixing the rendering problems would be great.

[RaulDJ]

Should we open a new issue for this other problem or is this one already OK...?

[Waelwindows]

@Nezarn, that's not the case. Strobo nights ran at 60 fps for me and it still had that weird slow mo motion on the characters

[RaulDJ]

@Waelwindows Just a few seconds with any other framerate that is not exactly 60 FPS are enough to cause lost of sync in the character movements, and we don't even get 60, we get 61.something.

[RainKikyou]

I recorded a 60FPS emulator working video, it is clear that the model action is bound with the number of frames together
video：https://youtu.be/cMfANyoPDqE

[Nezarn]

Its still not stable 60 (because it won't magically fix itself), so issues exist somewhere. (so stop spamming :P)

[RainKikyou]

I'm sorry to say that when the frame number is too high there will be such a graphics problem. So the number of frames must be stable at 60fps, high or low will be a problem
My actual frame rate is higher than the video to 10FPS, so some song can be stable 60fps
ps：Before the PDF will be the same graphics, of course, is not the same reason

[AniLeo]

Can someone retest? It's likely this is no longer an issue