Princess Maker 5 Portable half screen in Vulkan
sum2012 opened this issue · 33 comments
Test on v1.10.3-1290-g2399c5f90-windows-amd64
Try v1.6.3 version also have this problem
Only happened in Vulkan
frame dump:
recording.zip
Weird, the dump renders correctly on NVIDIA for me...
It happen in Samsung S6 Tablet ,lg v20 ,Blackshark 3
desktop : Windows 7 64 bit NVIDIA GT 710
Only happen in Vulkan
The bug maybe from these log:
27:32:826 user_main W[SCEDISP]: hle\scedisplay.cpp:936 Video out requested, not supported: mode=0 size=1024,512
27:32:826 user_main W[SCEDISP]: hle\scedisplay.cpp:942 80000104=sceDisplaySetMode(0, 1024, 512): invalid size
v1.10.3-1290-g2399c5f90 full log:
https://gist.github.com/sum2012/8503df8417c8ce8746c030911cb4f84d
Ok, thanks for letting me know. Nah, those are unrelated for sure.
It's quite strange, I can't seem to repro this problem with the recording, even on Android.
It might have some bug in reproducing 's code
gid15 from jpcsp explain this game "20:30:33 DEBUG ge - GUI - fbp fbp=0x04000000, fbw=1024
20:30:33 DEBUG ge - GUI - base 0x09000000
20:30:33 DEBUG ge - GUI - jump old PC: 0x09B30914, new PC: 0x09B3092C
20:30:33 DEBUG ge - GUI - Reloading GE Memory (0x04000000-0x04088000) to screen (480x272)
20:30:33 DEBUG ge - GUI - GETexture.copyTextureToScreen GETexture[0x04000000-0x04110000, 480x272 (texture 1024x512), bufferWidth=1024, pixelFormat=3(PSM_8888)] at 0x0
It seems this is because the game is rendering its screen at a high resolution (1024x512) and then resizing to the PSP resolution. "
Does age 96 is too long ?
36:20:413 root I[SCEKERNEL]: hle\scekernelthread.cpp:2007 276=sceKernelCreateThread(user_main, 08804114, 00000020, 524288, 80000000, 00000000)
36:20:413 root I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(276, 33, 09fffed0)
36:20:413 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 278=sceKernelCreateThread(exit thread, 0885a254, 00000011, 4000, 00000000, 00000000)
36:20:413 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(278, 0, 00000000)
36:20:414 user_main W[SCEDISP]: hle\scedisplay.cpp:936 Video out requested, not supported: mode=0 size=1024,512
36:20:414 user_main W[SCEDISP]: hle\scedisplay.cpp:942 80000104=sceDisplaySetMode(0, 1024, 512): invalid size
36:20:415 user_main I[FRAMEBUF]: common\framebuffermanagercommon.cpp:3 Creating FBO for 04000000 (z: 00000000) : 1024 x 512 x 0
36:20:415 user_main W[G3D]: common\framebuffermanagercommon.cpp:1424 Memcpy fbo upload 04400000 -> 04000000 (size: 100000)
36:20:444 user_main I[SCEUTIL]: hle\sceutility.cpp:333 0=sceUtilityLoadModule(00000300)
36:20:461 user_main I[SCEUTIL]: hle\sceutility.cpp:333 0=sceUtilityLoadModule(00000303)
36:20:477 user_main I[SCEUTIL]: hle\sceutility.cpp:333 0=sceUtilityLoadModule(00000302)
36:20:511 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 282=sceKernelCreateThread(SceWaveMain, 08858130, 00000010, 4096, 00000000, 00000000)
36:20:511 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(282, 12, 0897080c)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 283=sceKernelCreateThread(power thread, 0885a32c, 0000006f, 2048, 00000000, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(283, 0, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 284=sceKernelCreateThread(ms thread, 0885a454, 0000006f, 2048, 00000000, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(284, 0, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 285=sceKernelCreateThread(CRI ADX Audio, 08829e98, 00000016, 32768, 00000000, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(285, 0, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 286=sceKernelCreateThread(CRI ADX File, 08829f10, 00000018, 16384, 00000000, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(286, 0, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2007 287=sceKernelCreateThread(CRI Wave out, 08843534, 00000010, 16384, 00000000, 00000000)
36:20:527 user_main I[SCEKERNEL]: hle\scekernelthread.cpp:2102 0=sceKernelStartThread(287, 0, 00000000)
36:20:528 user_main I[SCEIO]: hle\sceio.cpp:1143 stdout: PSPCI: File cache was not hit. "disc0:/PSP_GAME/USRDIR/DATA.BIN"
36:23:029 user_main I[ME]: hle\scempeg.cpp:449 sceMpegInit()
36:23:757 CRI ADX Audi I[FRAMEBUF]: common\framebuffermanagercommon.cpp:1 Decimating FBO for 04000000 (1024 x 512 x 0), age 96
36:25:029 user_main I[FRAMEBUF]: common\framebuffermanagercommon.cpp:3 Creating FBO for 04100000 (z: 04000000) : 1024 x 512 x 0
36:25:035 user_main W[G3D]: common\texturecachecommon.cpp:949 Texturing from framebuffer at 04100000 +512x0
36:25:162 CRI ADX Audi I[FRAMEBUF]: common\framebuffermanagercommon.cpp:1 Decimating FBO for 04100000 (1024 x 512 x 0), age 6
The dump doesn't reproduce the issue, unfortunately. Maybe it's related to decimation - but that should be common to all backends.
But, this games draws using a 1024x512 framebuffer (including verts.) It's even texturing 1024x1024, which I actually wasn't sure was supported... I wouldn't be shocked if we had an assumption somewhere in the Vulkan code that 512x512 is the max.
In the dump at 127/190, it's doing a texture from self 1024x1024 -> 1024x512. It uses this to reduce the 1024x512 render down to 480x272. That's for sure the most unusual thing in this dump.
I don't think #13762 is the right fix, since basically that's just flushing texture state kinda often - it's bound to accidentally fix it if it's missing somewhere else.
What would interest me is comparing each time it rechecks texture params (DIRTY_TEXTURE_PARAMS), here:
bool textureNeedsApply = false;
if (gstate_c.IsDirty(DIRTY_TEXTURE_IMAGE | DIRTY_TEXTURE_PARAMS) && !gstate.isModeClear() && gstate.isTextureMapEnabled()) {
textureCache_->SetTexture();
gstate_c.Clean(DIRTY_TEXTURE_IMAGE | DIRTY_TEXTURE_PARAMS);
textureNeedsApply = true;This would help log more useful info:
master...unknownbrackets:dbg-13741
-[Unknown]
@unknownbrackets This is modify log
https://gist.github.com/sum2012/f6a5efda6327a86a9a2def9b6ca12541
That's interesting, it seems like it must be related to frambuffer as texture - I wonder if we're losing the offset?
I added more logging on the branch: master...unknownbrackets:dbg-13741
Also the most recent commit makes it only apply for framebuffers (at least in that scene.) It'll be interesting if it still works, or if it's now broken.
-[Unknown]
I forget log lvel default to error now.I re-do log
The screen still work in Vulkan
log; https://gist.githubusercontent.com/sum2012/319e2c5a4ac01b34f9718a2804ee4f0b/raw/3f1b6736d266e1c900b70f9888b82904d2d3481a/gistfile1.txt
Interesting, nothing is obviously different. I wonder if it's from flushing other flags.
Updated the branch again to skip some flags and log a bit more.
-[Unknown]
The screen still work in Vulkan
In the log ,I cannot see "B Set texclamp"
full log;
https://gist.githubusercontent.com/sum2012/884b26eec74c48d1f38ceb9dbc91eb51/raw/e6d8c31a981a6f10a57bf6dfe57ba73ce262f977/gistfile1.txt
Sorry, I think I must not've pushed - "New texture" shouldn't show anymore. Pushed now.
-[Unknown]
The screen still work in Vulkan
Do not hit these two log
ERROR_LOG(HLE, "Depal flush");
ERROR_LOG(HLE, "Disable depal");
full log:
https://gist.githubusercontent.com/sum2012/cc21160efc0edee43412213d25ed8c02/raw/0247830399a55fe9a76502380e3b35175768e5c4/gistfile1.txt
I pushed another commit - in theory it should still work and just log a bit less. If that's true, the next thing to try is making this (DrawEngineVulkan.cpp):
if (forceTexParamsDirty && !Memory::IsVRAMAddress(gstate.getTextureAddress(0))) {
forceTexParamsDirty = false;
}Simply always false.
forceTexParamsDirty = false;If this still works, it's not SetTexture() at all (sorry, I at first assumed it was), but maybe Execute_TexSize0 or something.
If it worked until that change, then it might be framebuffer->last_frame_used, InvalidateLastTexture();, some image rebind issue, or a sampler lookup thing.
-[Unknown]
Hope don't have undocumented flag in vukan
5 change The screen still work in Vulkan
log:
https://gist.github.com/sum2012/b80b062b07e3e1a1c93e8a9f24bfc3ca
6 change
if (forceTexParamsDirty && !Memory::IsVRAMAddress(gstate.getTextureAddress(0))) {
forceTexParamsDirty = false;
}Simply always false.
forceTexParamsDirty = false;The screen DO NOT work in Vulkan
log: https://gist.github.com/sum2012/ce934375c8f86738b31838eb4d3400d6
Very interesting. What if you change:
textureNeedsApply = true;
To:
textureNeedsApply = !texCacheDebugDifference;
But keep the 6 change?
-[Unknown]
Also I pushed another commit, which should log if I missed any other flags. If it doesn't log anything, and if textureNeedsApply = !texCacheDebugDifference; doesn't break it, then I'm really not sure what's causing this...
-[Unknown]
DO NOT WORK
log:
https://gist.github.com/sum2012/c7e109958ee67123f65ad17080e21d0a
textureNeedsApply = true;
To:
textureNeedsApply = !texCacheDebugDifference;
But keep the 6 change?
====================
I do not have time to do next change.
Hmm, well that implies that the imageView or sampler is changing, which is interesting. The next change would verify when you have time.
-[Unknown]
i ask you first.hope answer before i back home.
do latest change need include change 6 and 7 ?
No, it shouldn't include either one. Just what's in the branch.
-[Unknown]
change 8(?) still work
https://gist.github.com/sum2012/b5883ab62850191cbc869040a9a8cfca
Seem do not log new thing.
edit:Can we improve frame dump to record from game start auto and stop record when problem happen ?
I've updated the branch with another try: master...unknownbrackets:dbg-13741
Does this potentially stop it from logging #13741 - Force texture params check for tex %08x? If not, try change 6 or 7 again.
-[Unknown]
It is still logging #13741 - Force texture params check for tex %08x.
https://gist.github.com/sum2012/5ef3e717f8a40be2e8a90b6df9c32b3e
Change 6 or 7 screen NOT work
Does #14233 help?
-[Unknown]
Yes,fixed it,very thanks
Please note that OpenGL don't require that change
The change doesn't hurt much if anything, so that's alright. Probably the same flag gets set some different way in GL anyway, although I haven't looked into this...