(libretro) context_reset is broken

[orbea]

What happens?

When toggling fullscreen in RetroArch with f ppsspp renders a broken image breaking any game play. I'm told this was broken in an rebase when merging the core upstream?

What should happen?

Toggling full screen should work.

What hardware and operating system are you running PPSSPP on? GPU might matter if it's a graphical issue.

OS: Slackware64-current GPU: GK110B mesa-2018.01.18_5fc21c6_master-x86_64-1_git

Related issue: https://github.com/libretro-mirrors/ppsspp/issues/27

[hrydgard]

Yeah everything was badly broken for retroarch after the new GL threading rework, then @aliaspider swooped in and fixed it all up except resizing. Needs to be looked into.

[orbea]

@aliaspider Thanks for the fix!

[orbea]

@hrydgard and @aliaspider, actually this solution doesn't work here...

Instead of displaying garbage emulation gets frozen on a white screen.

[orbea]

Additionally apitrace doesn't like it and will exit when trying to toggle context_reset.

apitrace: warning: unknown function "glPolygonOffsetClamp"
apitrace: warning: unknown function "glWindowRectanglesEXT"
I: gpu_features.cpp:142: GPU Vendor : nouveau ; renderer: NVF1 version str: 3.1 Mesa 18.1.0-devel (git-5fc21c6044) ; GLSL version str: 1.40
I: GLRenderManager.cpp:154: Running first frame (0)
apitrace: warning: caught signal 11
apitrace: flushing trace
/usr/bin/../lib64/apitrace/wrappers/glxtrace.so+0x1f588c
/lib64/libpthread.so.0+0x1237f
/usr/lib64/libasound.so.2+0x5f5a3
/usr/lib64/libasound.so.2: snd_pcm_state+0x28
/usr/lib64/libasound.so.2+0x86588
/usr/lib64/libasound.so.2+0x8d952
/usr/lib64/libasound.so.2: snd_pcm_poll_descriptors_revents+0x53
/usr/lib64/libasound.so.2+0x53632
/usr/lib64/libasound.so.2: snd_pcm_wait+0x1a
retroarch+0xdf76d
retroarch+0x3f964
/usr/lib64/libretro/ppsspp_libretro.so: _ZN10CoreTiming21ProcessFifoWaitEventsEv+0x50
/usr/lib64/libretro/ppsspp_libretro.so: _ZN10CoreTiming7AdvanceEv+0x44
/usr/lib64/libretro/ppsspp_libretro.so: _Z18__KernelReSchedulePKc+0x12
?+0x4122e273
apitrace: info: taking default action for signal 11

Full log - https://pastebin.com/u78dMX8E Trace - http://ks392457.kimsufi.com/orbea/stuff/trace/ppsspp_context_reset.trace.xz

[orbea]

I discovered that the apitrace crash doesn't always occur. I'm not sure what the difference is?

Here is a more informative trace. http://ks392457.kimsufi.com/orbea/stuff/trace/ppsspp_context_reset2.trace.xz apitrace log - https://pastebin.com/8uHDiDYw

[orbea]

I am guessing this might have to do with how ppsspp and/or RetroArch is trying to set a 3.1 core context, which does not exist according to some mesa devs.

This recently caused issues with beetle-psx, see this issue. https://github.com/libretro/beetle-psx-libretro/issues/315

But if I use export MESA_GL_VERSION_OVERRIDE=3.2 neither the ppsspp libretro core or RetroArch will start (Beetle-psx does...). I also am not sure where either RetroArch or ppsspp are setting a default GL context?

[orbea]

RetroArch doesn't start because its using a compat profile apparently. Setting 3.0 or older works while 3.1 or newer doesn't. I supposed 3.1 should be exposed as a compat context in mesa now, but there might be some confusion and bugs around that.

As for ppsspp, I'm still not sure where its setting the GL profile context?

[unknownbrackets]

You must call SetGLCoreContext(true); when using a core profile context. We by default assume a compatibility profile.

See for example here: https://github.com/hrydgard/ppsspp/blob/37503270544372ee739ef272d4e56f005ea11490/SDL/SDLGLGraphicsContext.cpp#L43

Do not set it to true under a GLES profile.

-[Unknown]

[orbea]

My guess its currently using a non-core compat GL profile as it hits this line.

https://github.com/hrydgard/ppsspp/blob/master/libretro/LibretroGLContext.h#L15

[orbea]

Any updates on this issue? It would really be a big benefit for the libretro core if this could be solved.

[orbea]

I have just realized that vulkan was hooked up for libretro and that this is not a problem with Vulkan, only OpenGL.

[hrydgard]

Is this still an issue?

[orbea]

Yes, ppsspp libretro is still completely broken and unusable on linux.

[m4xw]

I have had simliar issues with my Switch port (it would crash tho, however on recent builds it renders no video and only audio after ctx reset), I figured it was because my hacky temporary GL loader. @orbea can you provide me with a picture of what the "broken image" looks like? Maybe this ends up being the same underlying issue. I will investigate this and other issues over the next weeks and probably rewrite parts of the core impl. So any infos you can provide me with are very helpful.

[orbea]

@m4xw There is not much to show, it starts off a blank white screen and then transitions to a blank black screen as the game proceeds.

[m4xw]

Ok thanks

[hrydgard]

Is this the same as #11253 ?

[orbea]

@hrydgard Partially, the savestate crash issue is different. The resolution change issue is the same as here.

[orbea]

This is most certainly not fixed in commit https://github.com/hrydgard/ppsspp/commit/1618aa8f8c56e072fba56f98bec0d74de7fbb24c.

[BParks21]

@orbea Sorry about that thought i was commenting on a different issue.

[hrydgard]

How bad is this now?

[raidenii]

Not sure if it's related - ppsspp libretro core on Linux (tested on x86-64 and aarch64) gives a black screen when starting a 2nd game in the same RA session, like mentioned in https://github.com/hrydgard/ppsspp/issues/11339.

[BParks21]

Any news on this issue? Would be nice to be able toggle fullscreen on and off with specific video drivers set. D3D 9 & 11 just crash, glcore goes to a black screen, and vulkan and gl work as expected.

[gouchi]

Here is some backtrace using glcore video driver toggling full screen.

[libretro INFO] [G3D] Context reset
[libretro ERROR] [SYSTEM] (../GPU/Common/PresentationCommon.cpp:CreateDeviceObjects:443) Critical: [vdata_ == nullptr] *** Assertion ***

(../GPU/Common/PresentationCommon.cpp:CreateDeviceObjects:443) Critical: [vdata_ == nullptr] *** Assertion ***

[libretro INFO] [SYSTEM] *** Assertion ***

Thread 1 "retroarch-debug" received signal SIGINT, Interrupt.
0x00007ffff55b001b in kill () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff55b001b in kill () at /usr/lib/libc.so.6
#1  0x00007fffe41ab4e1 in PresentationCommon::CreateDeviceObjects() () at /tmp/ppsspp/libretro/ppsspp_libretro-debug.so
#2  0x00007fffe4203819 in FramebufferManagerGLES::DeviceRestore(Draw::DrawContext*) () at /tmp/ppsspp/libretro/ppsspp_libretro-debug.so
#3  0x00007fffe41e4d57 in GPUCommon::DeviceRestore() () at /tmp/ppsspp/libretro/ppsspp_libretro-debug.so
#4  0x00007fffe41ffe09 in GPU_GLES::DeviceRestore() () at /tmp/ppsspp/libretro/ppsspp_libretro-debug.so
#5  0x000055555561fc24 in drivers_init (p_rarch=0x555556411a80 <rarch_st>, settings=0x55555657cd50, flags=2047, verbosity_enabled=true) at retroarch.c:33643
#6  0x000055555561be53 in video_driver_reinit_context (p_rarch=0x555556411a80 <rarch_st>, settings=0x55555657cd50, flags=2047) at retroarch.c:31804
#7  0x000055555561bed0 in video_driver_reinit (flags=2047) at retroarch.c:31816
#8  0x00005555555f42af in command_event_reinit (p_rarch=0x555556411a80 <rarch_st>, flags=2047) at retroarch.c:13385
#9  0x00005555555f54f0 in command_event (cmd=CMD_EVENT_REINIT, data=0x0) at retroarch.c:14021
#10 0x00005555555f7131 in command_event (cmd=CMD_EVENT_FULLSCREEN_TOGGLE, data=0x0) at retroarch.c:14862
#11 0x000055555562a30f in runloop_check_state (p_rarch=0x555556411a80 <rarch_st>, settings=0x55555657cd50, current_time=24732700664) at retroarch.c:38025
#12 0x000055555562ced8 in runloop_iterate () at retroarch.c:39067
#13 0x00005555555f8881 in rarch_main (argc=5, argv=0x7fffffffe078, data=0x0) at retroarch.c:15700
#14 0x00005555555f88e3 in main (argc=5, argv=0x7fffffffe078) at retroarch.c:15777

(gdb) info frame
Stack level 0, frame at 0x7fffffff9090:
 rip = 0x7ffff55b001b in kill; saved rip = 0x7fffe41ab4e1
 called by frame at 0x7fffffff9100
 Arglist at 0x7fffffff9080, args: 
 Locals at 0x7fffffff9080, Previous frame's sp is 0x7fffffff9090
 Saved registers:
  rip at 0x7fffffff9088

(gdb) info reg
rax            0x0                 0
rbx            0x555557e304e0      93825035076832
rcx            0x7ffff55b001b      140737309769755
rdx            0x1                 1
rsi            0x2                 2
rdi            0xdf13              57107
rbp            0x555558d60230      0x555558d60230
rsp            0x7fffffff9088      0x7fffffff9088
r8             0x555557e59770      93825035245424
r9             0x7ffff56f84e0      140737311114464
r10            0x7ffff557dfb0      140737309564848
r11            0x206               518
r12            0x5555555d2050      93824992747600
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x7ffff55b001b      0x7ffff55b001b <kill+11>
eflags         0x206               [ PF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

[gouchi]

@orbea this issue should be renamed to (libretro) context_reset is broken using gl or glcore video driver.

EDIT : Nevermind the issue happens also with d3dxx video driver.

[unknownbrackets]

Well, I took a quick look at the libretro.c file and it seems like the basic problem is that it calls reset without calling destroy first. I'm not likely to dig into this further, but I suspect the author of LibretroGraphicsContext.cpp was under the impression that ContextDestroy would be called before ContextReset.

It might be as simple as a flag to destroy everything before proceeding with the rest of reset, if destroy was never called.

Looks like this is an expected scenario: https://github.com/libretro/RetroArch/blob/15d28fe2eb8f8829c7cb792356a3563de2ecb9fa/libretro-common/include/libretro.h#L2472

I'm not very interested in libretro, but it's the first time someone posted a useful stack trace to this issue in 3 years, so figured I'd take a quick look. Hopefully that helps whoever is interested in actually fixing and testing this.

-[Unknown]

[bslenul]

As an additional info for anyone wanting to take a look at this, as mentioned in #12841 for some reason it doesn't crash if audio sync is OFF... 🤔 Could be completely unrelated however, idk.

Nope nvm, can't reproduce anymore, not sure what happened, maybe I've switched to Vulkan or something during my tests, but seems like it doesn't fix anything... sorry about that :/

[m4xw]

@bslenul can u check with "enable menu sounds"?

[KamiLordus]

It seems to me that the current version of PPSSPP performs even worse than a few months ago when it comes to switching fullscreen. DX11 and Vulcan crash when switching fullscreen in Retro Arch. Only GL works - but texture filtering doesn't work in this mode, so the graphics are much worse (for example GTA 3 Liberty City Stories).

[hrydgard]

What do you mean that texture filtering doesn't work? Seems very bizarre to me.

[KamiLordus]

Sorry, I wasn't specific enough. In dx11 mode textures filtering set to auto max quality, gives a very nice anti-aliasing effect. In GL textures filtering mode auto max in my case does not give a similar result. I tried to capture it in pictures, but without the ability to exit to the desktop (fullscreen switching), it's quite hard to capture the same moment.

GL filtering auto max:

DX11 auto max:

However, this is not the worst problem. The problem is that there is no option to switch fullscreen to window mode. Constant RA crash, I think even in GL mode it happened to me

[hrydgard]

Ah yes, auto max quality doesn't yet autogenerate mipmaps on OpenGL, which is required to get that smooth effect, which I agree is desirable.

As for fullscreen, no idea, as stated many times I'm not maintaining the libretro port, I just review and merge PRs for it as my focus is the standalone build.

[KamiLordus]

Thanks for the answer. I will try to report this problem in RA liberto. Maybe someone will have an idea.