Nayuta no Kiseki: Graphics glitch, flashing textures.

[orbea]

OS: Slackware64-current
Linux-4.5.4
mesa-8d63913_2016.05.09_master-x86_64-1_git
xf86-video-nouveau-b824d36_2016.01.13_master-x86_64-1_git
ppsspp-d6c2b6e_2016.05.15_master-x86_64-1_git
Nayuta no Kiseki English Patch 4.14

In one area of the game Nayuta no Kiseki I experienced the ground flashing whenever the camera moved.

Here is a trace made with apitrace showing the issue, it can be replayed with apitrace replay nayuta_no_kiseki_ppsspp.trace.
http://ks392457.kimsufi.com/orbea/stuff/trace/nayuta_no_kiseki_ppsspp.trace.xz

A log of the apitrace replay output.
http://pastebin.com/WMswsAuR

And a savestate for the issue.
http://ks392457.kimsufi.com/orbea/stuff/games/ppsspp/PPSSPP_STATE/NPJH50625_1.01_0.ppst.xz

Is there any other useful information I could provide to help debug this?

[unknownbrackets]

Hmm, does it have any affect if you enable/disable "hardware transform"? What about vertex cache (which requires hardware transform to be on)?

-[Unknown]

[orbea]

No changes with either hardware transform or vertex cache enabled / disabled, the flashing textures still occur.

[unknownbrackets]

Since it's the same developer, I wonder if this is somehow related to #8403. It could also be z-fighting.

Unfortunately, the GE debugger isn't totally fleshed out on platforms other than Windows. Last I checked, it works fine under WINE, but the fonts are screwy unless you have the real fixedsys. That would probably help debug it the most... hm.

Does it happen if you use "software rendering"? You can save state, stop the game, change it, and then load the state. It'll be slow, but if it works, that tells us it's probably not a math issue in the CPU emulation, or something.

-[Unknown]

[orbea]

It does not occur with software rendering, but that is as expected slow and unplayable.

What would a recommended build for using under wine be?

[unknownbrackets]

I think WINE 1.7 has been reported to work. I would expect it to work in the latest version. If not, it's probably a bug in either PPSSPP or in WINE.

For PPSSPP, I recommend the latest git build from here:
http://buildbot.orphis.net/ppsspp/

When you get it working, here's a guide on how to find the related draw commands from the GE:
https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger

-[Unknown]

[orbea]

v1.2.2-492-gfff898b
wine-staging-1.9.9-x86_64-1_SBo
wine-1.9.9-x86_64-1_SBo

I tested the latest git build from your link with wine-staging & ordinary wine, but I was not able to use the GE debugger due to wine issues...

Starting ppsspp, the game, loading the savestate and reproducing the issue all worked.

What does not work is that as soon as the GE debugger is started my entire window manager (spectrwm-3.0.1) freezes forcing me to ssh into my desktop from another computer to kill PPSSPPWindows.exe.

[LunaMoo]

https://github.com/hrydgard/ppsspp/compare/master...LunaMoo:anotherIDforRounding?expand=1

^ that should help, through not really sure if it's worth it, I mean it might make the game potentially much slower on weaker systems so if it happens only in one location it might just be better left as it is.

@orbea you can edit that "compat.ini" file manually without waiting for build and see if you're happy with it, just add NPJH50625 = true under [PixelDepthRounding], as mentioned it might make the game heavier. That file should be in ppsspp/assets folder.

[orbea]

Yes, I manually edited the file and that fixes it.

I have played the game for only a little bit and there may or may not be more instances of the issue. I will test more without this change and see.

[unknownbrackets]

Wow, that freeze doesn't sound like a good result. I wonder what caused that, I guess it couldn't handle multiple OpenGL instances?

Come to think, I was using the closed-source driver, since nouveau had been rendering some things incorrectly, when I tested that...

Is it enough to put the id in VertexDepthRounding? That is much less expensive.

-[Unknown]

[LunaMoo]

From what I checked vertex depth rounding wasn't enough to even make a noticeable difference. At least in the place from the savestate provided. With pixel depth rounding it actually still happens a bit, but get's noticeable only at x1 res, so not much of a problem.

[unknownbrackets]

Ah. I wonder if it happens just a bit even on a real PSP, perhaps.

I wish the narrow depth range approach worked sanely, because then it could be nearly free. Darn drivers. Vulkan doesn't even make it better, unfortunately, since this isn't a problem for other people:

The framebuffer depth coordinate zf may be represented using either a fixed-point or floating-point representation.
Depth/stencil formats are considered opaque and need not be stored in the exact number of bits per texel or component ordering indicated by the format enum. However, implementations must not substitute a different depth or stencil precision than that described in the format (e.g. D16 must not be implemented as D24 or D32).

I've considered making it try to run some tests against the display and read out usable depth values, or something. Even that won't work in some of the cases.

-[Unknown]

[hrydgard]

Well, on modern GPUs that support Vulkan we should have enough spare performance to use the pixel depth rounding approach anyway in the games that need it, so all is not lost. We may be able to make it smarter and only turn it on for 2D or 3D-as-2D geometry, for example, too. But yes, vertex depth rounding would be far neater.

[orbea]

With a little testing I found 3 other locations in that one level that that had similar flickering. Other levels so far have not reproduced it, but that still requires further testing.

The ppsspp GE debugger freezes left a lot of this in dmesg.
http://pastebin.com/BbtjdzFY

It seems it could be a similar issue to this if multiple GL threads are hitting nouveau at once?
mpv-player/mpv#2757

[hrydgard]

I think we might want to change the debugger to not use a 2nd GL context but instead have the main context render and readback the preview images. Would be a bit tricky though.

[unknownbrackets]

It's definitely simpler to not implement the zooming, panning, and other debugging features in a software renderer or force them upon the backends.

-[Unknown]

[orbea]

I have no interest in reporting issues for ppsspp anymore so I will just close this.

[hrydgard]

Like I said in the other issue, that's not how it works.

[unknownbrackets]

There's a possibility the lighting fixes improved this. It might also help to get a GE frame dump of this issue (if possible, I realize flickering is hard to catch.) These help a lot.

See here for instructions - using the web debugger you can avoid the dmesg issues too:
https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump

You can zip that and then drag and drop it into a reply here.

-[Unknown]

[orbea]

I would like to help, but it would be significant time and effort to get to a point in the game I can reproduce this which is not practical considering all the other current issues making ppsspp hard to use...

[orbea]

@unknownbrackets I can confirm this issue is still in the master (d0e2aa3). I tried making a GE frame dump, but I'm not sure I can catch the flickering without something like the multiframe GS dumps pcsx2 has.

recording.ppdmp.txt

[unknownbrackets]

Thanks, this is a great snapshot of the issue.

Here's the correct rendering on a PSP:

Here's what we render in GLES:

Software is largely correct:

The draw goes wrong at 43/199, and I think 44/199 too. Ultimately, it's using a src >= dst test, but the draw produces values that are SLIGHTLY lower (for example one pixel had 10115.108398 before, and was trying to write 10115.088867.) Rounding the vertices definitely won't help in this case, I can see why.

I think we should probably enable the pixel depth rounding flag for this game indeed.

Maybe we should consider noticing when games use >= or <= or = depth tests and potentially enable depth rounding by default...

-[Unknown]

[hrydgard]

I switched pixel depth rounding on in ad0ef74. Please try with a new build.

[orbea]

@hrydgard I've already been adding NPJH50625 = true in my own builds and this commit also does that. This mostly works, but the affected areas still show slight graphical noise when the player is moving near them. It is however barely noticeable.

I'm not sure if you wish to consider this fixed or leave it open for a more complete fix later.

[hrydgard]

I guess let's leave it open for now.

[ghost]

Try the dump on my phone using ppsspp development apk (latest)

opengl

vulkan

[hrydgard]

Looks fine to me. If the flicker is mostly fixed, let's just close this, not sure there's more we can practically do.

[orbea]

@hrydgard This did not show up in still images, only when playing the game. Has anything changed since NPJH50625 = true was added?

[hrydgard]

I don't know, but it was already reported that the flicker is minimal now, and I'm not sure how much closer we can get with hardware rendering really.