Persona 5 (NPEB02436) Bugs with textures

[Egrassa10]

During the game, bugs with textures occur periodically. Usually when I go into the menu, I go through the tabs, I go out. And so after a while that happens on the photo but with random textures, though with walls, though with persona. It helps reboot with the last save, the bug disappears. Tried to install on a pure version of the emulator, tried OpenGL instead of Vulkan, but the bugs are the same. The computer is new, the GTX 1080 graphics card, the processor i7-8700k, 16GB of RAM. Is there any idea what this is for?

[Egrassa10]

if it need:

S {rsx::thread} RSX: New program compiled successfully x4121 U {PPU[0x1000000] Thread (main_thread) [0x008faf44]} cellSysutil TODO: cellVideoOutConfigure(videoOut=0, config=0x2044c480, option=0x0, waitForEvent=0) E {rsx::thread} RSX: NV3089_IMAGE_IN_SIZE: Invalid blit dimensions passed S {Audio Thread} XAudio 2.9 initialized S {PPU[0x1000000] Thread (main_thread) [0x012549ac]} PPU: LLVM: Loaded module v2-librtc.sprx-9CB190F178FA7E82-skylake.obj S {PPU[0x1000000] Thread (main_thread) [0x012549ac]} sys_prx: Loaded module: /dev_flash/sys/external/librtc.sprx E {PPU[0x1000011] Thread (game contents hdd install) [0x001a5c14]} 'cellGameGetSizeKB' failed with 0x8002cb09 : CELL_GAME_ERROR_ACCESS_ERROR [1] U {PPU[0x1000000] Thread (main_thread) [0x01255038]} sys_prx TODO: _sys_prx_unload_module(id=0x2300c100, flags=0x0, pOpt=0x0) S HLE: XInput device 0 reconnected E {PPU[0x1000015] Thread (UNLOCK Thread) [0x001977f4]} sceNpTrophy: sceNpTrophyRegisterContext(context=0x1, handle=0x2, statusCb=0xce3f18, arg=0x0, options=0x1) E {PPU[0x1000000] Thread (main_thread) [0x009011a4]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [1] U {PPU[0x1000016] Thread (addContSyncThread) [0x01255038]} sys_prx TODO: _sys_prx_unload_module(id=0x23011800, flags=0x0, pOpt=0x0) S {rsx::thread} RSX: New program compiled successfully E {PPU[0x1000000] Thread (main_thread) [0x00197a10]} cellNetCtl: cellNetCtlNetStartDialogLoadAsync(param=*0x2044c4b0) S {rsx::thread} RSX: New program compiled successfully x7 E {PPU[0x1000000] Thread (main_thread) [0x009011a4]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [2] E {rsx::thread} RSX: Format incompatibility detected, reporting failure to force data copy (VK_FORMAT=0x2C, GCM_FORMAT=0x9F) E {rsx::thread} RSX: Format incompatibility detected, reporting failure to force data copy (VK_FORMAT=0x2C, GCM_FORMAT=0x95) S {rsx::thread} RSX: New program compiled successfully x11 E {PPU[0x1000000] Thread (main_thread) [0x009011a4]} 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [3] S {rsx::thread} RSX: New program compiled successfully x12 E {rsx::thread} RSX: nv406e::semaphore_acquire has timed out. semaphore_address=0x403005A0 S {rsx::thread} RSX: New program compiled successfully x4 E {rsx::thread} RSX: nv406e::semaphore_acquire has timed out. semaphore_address=0x403005A0 S {rsx::thread} RSX: New program compiled successfully x2 E {rsx::thread} RSX: nv406e::semaphore_acquire has timed out. semaphore_address=0x403005A0 x2 S {rsx::thread} RSX: New program compiled successfully x19 E {PPU[0x1000000] Thread (main_thread)} Stat: 'sys_ppu_thread_detach' failed with 0x80010005 : CELL_ESRCH [x12]

[haywoodspartan]

I also have the same issue with this as well. It seems if the game runs for too long it starts giving me corrupted textures like the ones above.

[Egrassa10]

Well, I understand this is not at all. There must be some reason? Some for all the passage did not encounter this bug

[andOlga]

Duplicate of #4298, please close. This is essentially a problem with the game code itself, or more precisely with the emulated threads stalling for too long and the game reacting to this in a weird way. You can see what kd-11 had to say about the issue in the earlier thread. Your best bet is finding the nearest save spot and restarting the game.

[haywoodspartan]

Is the rsx option still in the config file for the latest builds or has it been deprecated?

On Wed, Apr 18, 2018, 12:34 PM tlm-2501 notifications@github.com wrote:

Duplicate of #4298 https://github.com/RPCS3/rpcs3/issues/4298. This is essentially a problem with the game code itself, or more precisely with the emulated threads stalling for too long and the game reacting to this in a weird way. You can see what kd-11 had to say about the issue in the earlier thread. Your best bet is finding the nearest save spot and restarting the game.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RPCS3/rpcs3/issues/4457#issuecomment-382449424, or mute the thread https://github.com/notifications/unsubscribe-auth/AGSVQ4ROADOJr8UM84jhgFCcvydvp6Tfks5tp2sYgaJpZM4TaEtj .

[haywoodspartan]

Sure if I didn't have to load massive shader cache everytime

On Wed, Apr 18, 2018, 6:15 PM SpinningSlash notifications@github.com wrote:

FYI Its faster if you just save and reload then rebooting the game or application.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RPCS3/rpcs3/issues/4457#issuecomment-382546344, or mute the thread https://github.com/notifications/unsubscribe-auth/AGSVQ97S-pJ4XR-pflv5Lo_SF4FywPkNks5tp7sEgaJpZM4TaEtj .

[Egrassa10]

I'm not particularly versed in the device itself and the emulator code, but let's say you can use the setting on the CEMU emulator, like to compile the shaders and cache only the graphics card (or most of the part), like even the space on the disk is allocated for this particular case. Who tried something like that? Well, or the question I'll put it this way, if the problem in the large volume of shaders accumulated during the game, will the constant cleaning of the compiled shaders help?

[ghost]

@tlm-2501 if RPCS3 Going to be perfect in emulation then this bug have to be fixed as well, maybe a "Game.ini" File that have Special options for Specific games do the trick ( just Like PCSX2 )

[andOlga]

Game-specific hacks will never exist within RPCS3 itself, it goes against the emulator's policy. What should happen instead is the emulator being efficient enough for this desync not to happen. In other words, this problem should just "go away" as the code becomes more optimized and faster.

[Egrassa10]

Here is a post from a neighboring topic:

"Its very unlikely to be just a coincidence - its is a fairly serious issue whenever a cell core stalls and takes down the graphics chip. Try setting a much higher timeout (in older builds the waiting was infinite) like 30 seconds (30000000) in the yml configuration. Generally once you see an error like that, or the other fatal errors about a spurs kernel crashing, expect very bad things to start happening. I'd say, find the next save spot and restart the emulator. There are a few games with very broken emulation where the renderer ignoring the stalling in cell is not a big deal but those are few and its just a lucky coincidence."

Referring to this, the question is, did anyone try to learn the timing of the response? If so, which lines are responsible for this? In the post is not particularly clear: ( By the way, talked with those who passed the person without these bugs at all. The only difference was that they passed a year ago approximately and the version of the emulator was accordingly different

[kd-11]

Closing as duplicate. Semaphore timeout duration still exists in the config file, I would suggest upping that value and risk longer stalls if the glitches are happening alot. Ofc also removing spu tweaks (spu thread count to auto, no loop detection, no priority change) should theoretically fix the issue at a great performance loss.

[ruipin]

I see this exact same issue.

The above suggestions don't work, I get regular texture glitches and timeouts even if I set the semaphore timeout to a larger value. With huge timeouts (e.g. 30s+) the number of corrupted textures is significantly reduced, but still present, and it requires waiting for the whole timeout period every +/- 10 minutes (it's quite frequent). Disabling the SPU tweaks mentioned makes no difference.

@kd-11 As mentioned here, reverting to rpcs3-v0.0.4-2018-02-12-95c6ac69 fixes the issue completely even with the default timeout and aforementioned SPU tweaks enabled, so this looks like a regression from RPCS3 and might be worth reopening.

[korkyporky]

@ruipgpinheiro I tried playing using 0.0.4 to avoid the problem. Downside is, game hang after a short while.

[ruipin]

@korkyporky I've been trying to figure out what is causing this in the other issue https://github.com/RPCS3/rpcs3/issues/4298

There is a workaround for the latest version as long as you are willing to build RPCS3 yourself.