[Phantasy Star Portable 2 US] Debug Console Spam E[G3D] : Gpucommon.cpp:613

[eleriaqueen]

When I started the Debug Console with the game Phantasy Star Portable 2 US the console got filled with these :
I'm running 0.7.6 - 547

30:56:857 user_main E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0001 0000
30:56:858 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0004 0000
30:56:858 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0005 0000
30:56:858 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0006 0000
30:56:858 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0007 0000
30:56:858 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0008 0000
30:56:891 user_main E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0001 0000
30:56:891 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0004 0000
30:56:891 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0005 0000
30:56:891 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0006 0000
30:56:891 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0007 0000
30:56:891 idle0 E[G3D]: GPUCommon.cpp:613 Signal without wait. signal/end: 0008 0000

[papel]

@unknownbrackets
I do not know how logs without visible bug are important.
These log entries are absent in v0.9.1-951. The new log has some red entries with UNIMPL.

32:35:196 HLE\sceKernelModule.cpp:612 W[LOAD]: Unknown syscall in known module: sceNp 0x1d60ae4b

32:43:717 user_main    E[ME]: HLE\sceMpeg.cpp:1296 UNIMPL sceMpegAvcInitYCbCr(09092700, 1, 480, 272, 086091c0)

32:44:838 user_main    E[ME]: HLE\sceMpeg.cpp:837 UNIMPL sceMpegAvcDecodeFlush(09092700)

32:36:500 user_main    E[KERNEL]: HLE\sceKernel.cpp:668 UNIMPL sceKernelReferGlobalProfiler(08babc38)

If I enable "read from framebuffer to memory", a known bug will appear and I will see many things like:

05:57:934 idle0        E[SCEGE]: GLES\Framebuffer.cpp:1147 glReadPixels: GL_INVALID_OPERATION

If a game does not need "read from framebuffer to memory" to run fine, but the game has problem with this option enabled, is it an emulator bug?

[unknownbrackets]

I think they could be important since it may be a bug in hiding. For example, it might cause random events to never happen, or etc. But some log entries are completely innocent (like missing files, often), so it's hard to say.

I've noticed sceKernelReferGlobalProfiler in another game too I think, it could be important.

sceMpegAvcInitYCbCr / sceMpegAvcDecodeFlush are maybe actually implemented mostly.

glReadPixels: GL_INVALID_OPERATION probably means a bad component order or something, or just that the error flag was not cleared before the call.

As far as read to memory breaking things - well, that's why I see the option as a hack. On the PSP, a game can say "my canvas is 1024 pixels tall", and then only draw to the top 24 pixels of it. The other 1000 rows will not be modified.

In PPSSPP with that option, the memory for the other 1000 rows will be wiped. It might've had something important in it, in which case the game will likely be broken or glitchy. The game may have just been lazy since it didn't matter if it said the correct number or not anyway.

To combat this, we could do something like reading framebuffer data from memory the current operation writes framebuffer data to memory, it's confusingly named), which would probably cripple performance. Might still be faster than the softgpu.

Personally, I am only really concerned with "buffered rendering" bugs. Most of them are solvable. I think static analysis (detecting a function the game uses to blit vram, for example, as in Trails in the Sky) could even detect many types of pixel poking and work fine in buffered rendering, and be fast too. That's not to say any of it is easy.

-[Unknown]

[thedax]

Any need for this issue to stay open now that the original error message in the first post has been reduced to a debug log?