The game looks like the colors (for the 3D stuff) are semi-inverted(?)

Taking a look at the game with renderdoc, you can see that at some point, the game is rendered correctly (just miku's skirt is broken)
https://www.dropbox.com/s/6pkncvlgl2tfijv/dt2ndogl.rdc?dl=0

shaders: https://www.dropbox.com/s/sj5psv7of60hc7y/dt2ndogl.zip?dl=0
Vulkan is ofc broken on amd (like with the other issue), but behind the garbage it looks the same as ogl.
Seems to be using unbound textures in shader calculations. Will check why the texture would be null in this case. Might be an issue with determining whether to disable textures or maybe bind a dummy textre instead of binding null.
Its a shader bug actually.
in fact the vulkan shader perform worse( the graphics is broken)


But in the cartoon rendering repertoire shaders more normal work

video:https://youtu.be/_zv6a_NDFT0
@RainKikyou Vulkan validation layers are extremely slow. If you have debug output turned on, you should turn it off for performance. If that is not the case, I'm unsure why your performance is so slow. From the trace sent to me, its not a very complex game to render.
@kd-11 yep, its a 60 fps game, and with vulkan (and LLVM) it can nearly run on fullspeed https://www.youtube.com/watch?v=u5ll_B_UHAs (also you can see the amd issue how it looks in this game xD) so idk what did he do
@kd-11 I have been a default, and does not turn debug output,also can not call llvm
The number of frames is such

2and vullkan https://youtu.be/9nHwrw2JkYQ extend vullkan https://youtu.be/uKaa_0SeINg
@kd-11 (I realize this is off topic but I hope it's okay since it's in response to what you said. I apologize if it's not) I have that extremely slow effect too even with LLVM. I get about 45FPS(Vulkan)/27FPS(OGL) according to the titlebar and the rhythm game part plays normal speed but the background PV plays just as slowly as in @RainKikyou video. My system is i7 3770k @ 4.2Ghz and AMD R9 290 and I'm using latest rpcs3. I'm seeing about 20% CPU usage and 15% GPU usage. I'm using the same settings as @Nezarn (I know this because he gave them to me).
Perhaps there's an actual issue going here that should have it's own report? Again apologies for the off topic.
@kd-11 i forgot to mention, but i get this spammed in the log with ogl sometimes (idk if its relevant):
·E {rsx::thread} RSX: reserved allocation exceeded. check for corruption!
That issue is fixed with my latest pull request. It was a regression introduced by the refactoring.
This issue affects Virtua Fighter 5 too (by the looks of it, when that game booted before http://www.emunewz.net/forum/showthread.php?tid=158744&pid=233400#pid233400)
@kd-11 I've played around in Renderdoc, maybe this is a Vertex Shader issue, since if i comment out this,
tmp1.x = vec4(exp2(-tmp1.xxxx)).x;
or this
tmp0.x = vc[467].wwww.x;
in the vertex shader, it looks semi-fine (except that its a little bit dark, as if the saturation is less than it should be)

and the final rendered pic would look like this

Thanks. I now know where to start looking. The first step is usually to figure out what the shader is trying to do and then fix whats broken in the pipeline. Hopefully I can find some time over the weekend to analyze this.
@Sarania Did you solve your sluggish performance? I'll try to restore and improve the performance counters so we can see where the game is spending all that time. Hatsune miku games are usually easy to run.
@kd-11 There are some performance improvements but not enough,Such as the following picture
This is the 4.1 GHZ



This scene 4.0GHZ state only 18fps

@kd-11 btw in this game there are some extreme slowdowns, for example https://youtu.be/KumW8B-hpJY?t=2m27s (this is a video from PS3, and at ~2:27 you can see bunch of neon lights, now those are killing FPS big time (50+ -> ~10-20) )
Based on GPU-Z the GPU is starved (load is at 37%). I'm assuming the problem is that we're probably stalling on synchronization since I don't see any CPU core getting maxed out. You can test by running with null renderer. You cant see output since it doesnt use the GPU, but it gives a baseline CPU performance.
@kd-11 Romeo & Cinderella Is still around 40fps

@kd-11 now that i've checked GPU-Z, my card has yet another issue in Vulkan, yay. xD (always 100% gpu usage in Vulkan, even on 2D stuff, and its not any game's fault, since even Hello World sample has 100% gpu usage too O.o)
Also in this game for me, GPU usage in OGL is weird, sometimes i hit as low as 2%, max it hits is like ~80%, but it fluctuates a lot, also there are slowdowns even when the gpu usage is at only 60%
@RainKikyou what if you use LLVM? With LLVM i get fullspeed with Null renderer + my cpu starts to slow down its turbo boost since cpu usage is so low (with null renderer, also i've used Romeo and Cinderella too)

without LLVM:

Im not a dev, but i think we have a bottleneck or threading\timing issue somewhere.
Usually caused by synchronization stalling, so yeah, its probably a threading issue. I need to optimize OGL backend again but I usually tackle that when there isn't much to work on. Vulkan could use some minor optimizations as well.
Again, once again. 6700K can not use llvm

Utilities/JIT.cpp:254
.setMCPU(llvm::sys::getHostCPUName() == "skylake" ? "haswell" : llvm::sys::getHostCPUName())
Something like this.
@Nekotekina thank,can use llvm.but the number of frames is extremely unstable, and there will be broken sound appears
Up to 50 FPS or so

@RainKikyou @Nekotekina yep, in the 2nd game sound is stuttering with LLVM, but in the Extend version its not. (another sample for threading issue?)
This is the case, but the number of frames is still not as stable as 2and so bad
use llvm:裏表ラバーズ,Rolling Girl,初音ミクの激唱-pv
https://youtu.be/F7xkNW3aJYc
I feel this game is not real 60fps, I played PDFT (the same 60fps) so I can clearly feel this video reached full speed but did not reach 60fps
初音ミクの激唱, Look this Way, Baby
https://youtu.be/NpvW_MnuKGY
as well as with the PDF 2d material can not read Take the question
http://imgsrc.baidu.com/forum/cp%3Dtieba%2C10%2C727%3Bap%3Drpcs3%B0%C9%2C90%2C735/sign=c8dfbdbaa0d3fd1f2244aa7e592b477e/f1a281025aafa40f01afe049a364034f79f0198e.jpg
http://imgsrc.baidu.com/forum/pic/item/5f9652da81cb39dbdf6eb7acd8160924aa183074.jpg
I recorded the emulator and ps4 FT comparison video, although there is something wrong, but still want to be able to help, ps4 the FT and ps3 DT is essentially not very different
https://www.youtube.com/watch?v=NDf9G4uQD3o&index=2&list=PLSIFK7HFXCRYdRdo8E6BHzQcGeI7SoLds
@kd-11 i see you made some work towards ogl debug overlay, so i thought i try it (if it works already), if i stop emulation it crashes the emulator with one file from amd driver (i guess ogl), but ingame it can show stuff already, so i made some pics:
http://i.imgur.com/8moKHDD.png
http://i.imgur.com/PDTFwRR.png
http://i.imgur.com/PR6TgBC.png
http://i.imgur.com/0XJ0j9O.jpg
http://i.imgur.com/Ge8ujjT.jpg
Some of the counters aren't done yet, although it seems at least on opengl we are limited by buffer uploads which is expected. I'll work on that. Vulkan should be more interesting once I'm done with it as buffer uploads are not as problematic, and we can easily tell if we are limited in cell emulation or rsx emulation.
@Nezarn You can try from that branch again. Counters are mostly done, so you should see the bottleneck pretty easily.
@kd-11
Vulkan: http://imgur.com/a/mPdYj (from some strange bug GPU usage is always 100 (even on master, and even with for example the Hello World sample)
OpenGL: http://imgur.com/a/STZvN (GPU usage is fluctuating a lot, sometimes it even hits 0, then 28, 45, 78, the highest i've seen was 90%, but that wasn't at where\when the slowdowns came)
Problem is with cell emulation. Screenshots where ogl is running at mid-30s have about 50fps theoretical speed. The thread is stalling elsewhere and not in the GL thread. We're losing about 8 ms which is alot.
When looking into the issue, I realized that the emulator is slower now compared to builds from several months ago.
@kd-11 are you sure its cell issue? Not RSX? I made these screenshots while using LLVM, and also when the camera zooms in this song, FPS is Max, 60.
https://www.youtube.com/watch?v=KumW8B-hpJY Im talking about for example in this video at 0:38 (btw this is how the game should look), also its funny that at 1:31 Miku opens the door, now that doesn't happen on rpcs3, she just walks through it xD
When you have time, can you look at the shader issue at least? (since i guess for threading issue fixes we need to wait until Nekotekina does some magic :P)
Shader is probably due to incomplete vertex texture fetch:
tmp0.x = textureLod(vtex0, tmp0.xyxz.xy, 0).x;
...
tmp1.x = (tmp0.xxxx * vc[467].zzzz).x;
tmp1.x = vec4(exp2(-tmp1.xxxx)).x;
vtex0 is not enabled in rsx however. I'm assuming its supposed to be another texture index other than zero. Problem is that we have not yet mapped the source texture index from the rsx program bytecode and I haven't had time to research this.
I'll have find a way to get the raw binary programs to dump from the emu rsx so that I can analyze them.
@Nezarn Try from this tree https://github.com/kd-11/rpcs3/tree/gl
There's a hack there to attach any active vertex textures to index zero. It'll write alot of info to the log as well. Post the rpcs3.log and resulting renderdoc file. Its openGL only for now.
@kd-11 shader+log: https://www.dropbox.com/s/kscq3mabdrsrrsz/rpcs3.zip?dl=0
https://www.dropbox.com/s/o7be5b2mts3x0es/ogl.rdc?dl=0 renderdoc
Also im gonna edit the title since the Dreamy Theater trilogy use the same engine (i just assume the 1st game has the same issue, since that can't go ingame on rpcs3 until someone implements PSP connection via usb) and has the same issue (and i posted this shader and renderdoc from Extend because this game has less threading issue (2nd sometimes gets stuck loading))
Found the issue. I'll add the fix to my pending pull request but I'll need to debug some more to analyze the vertex texture stuff. Anyway, here's what it looks like:

@kd-11 nice, looks pretty close to PS3 (as you can see from the video i've linked 4 comment above)
edit: by the looks of it, only some lighting + shadow is missing
@kd-11 btw with partial fix did you mean its only for opengl? (i see that you changed that stuff for vulkan too, but vulkan is still broken)
Vertex texture fetch needs to be fixed before you see proper results. Only my gl branch with the hack can render correctly at the moment. Without working vertex textures, the output is unchanged.
@Nezarn Pull from my branch again and post the rpcs3.log. I should get the info I need to fix that vertex texture from that.
Well, but there are such problems, there will be vulkan

@kd-11 https://www.dropbox.com/s/y6itoa9ecbx0hn0/vulkan.zip?dl=0 (if log isn't enough, i will try get a renderdoc too (and that will take a while since the version that works for you is quite unstable for me >.<)
Log is enough.
@Nezarn https://ci.appveyor.com/project/kd-11/rpcs3/build/1.0.329 should be a proper fix for both vulkan and ogl. if it doesnt work, just post the shader log.
Is it fixed on opengl? The shaders looks correct.
@kd-11 yep, only Vulkan is still broken
Capture a renderdoc vulkan trace, version 0.31. To ensure that it does not crash for me, after capturing a single frame, exit the emulator first by closing the window by clicking the X and then immediately close the emulator. Renderdoc will then load the trace automatically. Traces captured using this method work for me somehow.
Crashes my driver :(
I'm not sure why vulkan would still not be fixed. Try https://ci.appveyor.com/project/kd-11/rpcs3/build/1.0.330 and see if anything changes.
Still looks the same

edit: actually its a little bit darker compared to master

Here's mine too, @kd-11 : https://aww.moe/x1vsme.rdc
I hope it helps a bit.
@RainKikyou that problem is easy, the textures have an alpha map, it seems that the shader isn't using the alpha or is set to an incorrect alpha mode, i currently can't run extend. because i don't have a save. but when i can. il try digging around in render doc to find a fix for this myself
@Nezarn option 2. Use vktrace commandline utility. You can find it in your
To record, run "vktrace -p rpcs3.exe" from the rpcs3 directory. Use the command window for this because even after you close the app it continues recording until you kill it with Ctrl+C. It will capture a very large trace file, so be quick to test and close it. Compressing using something like 7-zip should make the size much smaller after you're done.
@kd-11 https://www.dropbox.com/s/ygt4oe6yw4h5cqb/vktrace_out.7z?dl=0
I've looked at this and it will be interesting at playback, i hope theres a pause option XD (ingame with this trace, it ran too fast, and since i didn't recorded a lot, it will end soon)
Should i try and make another (with a full song in PV mode where i don't need to press anything since its slow with vktrace) ?
as long as the error is visible, it should be fine. If it fails, I'll just have to modify the emulator to dump info to the log as usual.
i've managed to get the code, i've added some comments to help explain what each line does. funfact this shader is the exact same one found in pdf.
(it's layman talk, so please bear with it, it's probably not gonna explain what it does effect wise, it just explains what the code does)
here it is
http://pastebin.com/SjgyUtkr
That shader is common in these games. The bugs usually originate elsewhere in the emu though, might be a texture swizzle mapping; those .yw swizzles might actually match .xz components if the texture was not properly set up.
@Nezarn https://ci.appveyor.com/project/kd-11/rpcs3/build/1.0.331
The trace also crashed, but I think the sdk version i'm using is outdated. I'll update and retry. In the meantime dump rpcs3.log generated by that build.
@kd-11 Here is mine: https://aww.moe/cf1kq5.log
@kd-11 https://www.dropbox.com/s/25uqs2guan6dasp/log.zip?dl=0
edit: just in case i've uploaded another trace, with a full song this time https://www.dropbox.com/s/kj4ed9qkp5actlr/vktrace_out_fullsong.7z?dl=0 (if you can sort out your crash, this is more useful than the first one, since you can see an extra minor bug in it at title screen)
I finally found the issue. It affected some samples as well, and I kept wondering why my register decode fix did not fix this.
Anyway here it is: https://ci.appveyor.com/project/kd-11/rpcs3/build/1.0.332~~
Oops. Forgot to commit a file
Proper build https://ci.appveyor.com/project/kd-11/rpcs3/build/1.0.334
The fix has been added to the pending PR so we can close this as soon as its merged.
@kd-11 Holy s*, the absolute madman:
http://i.imgur.com/3CteyiJ.jpg
http://i.imgur.com/YqV55mH.jpg
http://i.imgur.com/mmUcAXF.jpg
http://i.imgur.com/9Relc4l.jpg
Lightning is still a bit strange in some situations but the main problem is fixed.
@Waelwindows
savadata
https://drive.google.com/open?id=0B4z-S0oOZ2FgWW5IVlVDN3FDNmc
I hope to use skylake llvm do not need to re-compile their own, so too much trouble, hoping to merge as soon as possible to the master
I would like to point out that with this game the emulator runs at higher framerate with the FPS cap set at "60" instead of "Off". I don't think it makes much sense...
Moreover, with "Off" it never gets past ~63 FPS even when looking at the sky or some plain texture except when the game shows only pictures, which some PVs have.
@kd-11 well good job. however there's a problem.
1st thing's first. when playing the game the fps is stuck at 30. this could be from my end.
2nd thing is. when sometimes the lighting is stuck on a previous level's lighting
e.g. i played sound which has orange lighting, then played packaged which has white lighting
the game uses that orange lighting of sound
We ought to close this ticket as the original problem of broken color indexing was fixed.
I'm gonna open another issue for the speed issues
Most helpful comment
Utilities/JIT.cpp:254
Something like this.