Princess Maker 5 Portable half screen in Vulkan

[sum2012]

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

[hrydgard]

Weird, the dump renders correctly on NVIDIA for me...

[sum2012]

It happen in Samsung S6 Tablet ,lg v20 ,Blackshark 3
desktop : Windows 7 64 bit NVIDIA GT 710
Only happen in Vulkan

[sum2012]

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

[hrydgard]

Ok, thanks for letting me know. Nah, those are unrelated for sure.

[sum2012]

Opengl fixed in d8334ba in #13301
The game 's screen in old version same with Vulkan
Any chance to fix in Vulkan too ?

[hrydgard]

It's quite strange, I can't seem to repro this problem with the recording, even on Android.

[sum2012]

It might have some bug in reproducing 's code

[sum2012]

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. "

[sum2012]

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

[unknownbrackets]

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]

[sum2012]

@unknownbrackets This is modify log
https://gist.github.com/sum2012/f6a5efda6327a86a9a2def9b6ca12541

[unknownbrackets]

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]

[sum2012]

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

[unknownbrackets]

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]

[sum2012]

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

[unknownbrackets]

Sorry, I think I must not've pushed - "New texture" shouldn't show anymore. Pushed now.

-[Unknown]

[sum2012]

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

[unknownbrackets]

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]

[sum2012]

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

[unknownbrackets]

Very interesting. What if you change:

textureNeedsApply = true;

To:

textureNeedsApply = !texCacheDebugDifference;

But keep the 6 change?

-[Unknown]

[unknownbrackets]

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]

[sum2012]

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.

[unknownbrackets]

Hmm, well that implies that the imageView or sampler is changing, which is interesting. The next change would verify when you have time.

-[Unknown]

[sum2012]

i ask you first.hope answer before i back home.
do latest change need include change 6 and 7 ?

[unknownbrackets]

No, it shouldn't include either one. Just what's in the branch.

-[Unknown]

[sum2012]

change 8(?) still work
https://gist.github.com/sum2012/b5883ab62850191cbc869040a9a8cfca

[sum2012]

Seem do not log new thing.
edit:Can we improve frame dump to record from game start auto and stop record when problem happen ?

[unknownbrackets]

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]

[sum2012]

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

[unknownbrackets]

Does #14233 help?

-[Unknown]

[sum2012]

Yes,fixed it,very thanks

[sum2012]

Please note that OpenGL don't require that change

[hrydgard]

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...