glideN64 is corrupted for most games

[Panderner]

Hi the graphics are almost corrupted most games even glideN64-Very-Accurate on mupen64plus fz and libretro, I'm using PowerVR ge8320 (mediatek Helio p22) android phone

Comparison:

Libretro mupen64plus-next (normal and gles3 versions):

Mupen64plus fz:
In glideN64 very accurate the polygon and textures are glitchy

In glideN64 medium same as libretro core

Super Mario 64 used for comparison and it happened for most games

[m4xw]

These Issues started appearing when pulling the following changes in from upstream: libretro/mupen64plus-libretro-nx@16baae7

[gonetz]

@m4xw the commit contains almost all changes since the PR 4.0
If we want to find the problem, we need to bisect to the wrong commit in GLideN64 repo.
@fzurita can you find, when the problem appeared?

[gonetz]

@fzurita I just tested Mupen64plus fz from Play Market. It works correct. Which version of GLideN64 it uses?

[m4xw]

@gonetz he told me 2 days ago that he didn't update it yet, so I assume the reporter compiled it himself.

[m4xw]

However we suspect it's related to the shader changes.
fwiw shader cache breaks too on nvidia shield android with gles, no issues with OpenGL (on switch via nouveau, and lakka switch with nvidia drivers)

[gonetz]

@m4xw I modified shaders in commit 2d712f2.
Could you make android build from previous commit 993960f and compare with 2d712f2?

[m4xw]

@gonetz Sorry but I dont have a dev env set up since we switched NDK version.
I was refering to these exact shader modifications you did, but it's not easy to bisect these issues with my fork since I always have to rebase all my commits on top the commit you showed, also would be broken anyway without a cherrypick of 34c6cae
Can do it at my workstation at the office but not before next week :/

[fzurita]

I'll go ahead and take a look, I have some time today. @Panderner which phone do you have?

[m4xw]

Thanks man, that would be great.
@fzurita

PowerVR ge8320 (mediatek Helio p22)

You will also find some more infos on my fork's issue tracker libretro/mupen64plus-libretro-nx#99

This might also be related (I remember it working but would need to double check) libretro/mupen64plus-libretro-nx#101
And it might've also caused a regression for bgStriped on Windows+GL libretro/mupen64plus-libretro-nx#98
Weirdly enough that seems linked to monitor refresh rate.
I didn't confirm Yoshi's pacing issues, but I have a report that this also appeared when pulling in all the new changes from the commit i mentioned.

So thats about all detail's I know related to the recent upstream changes, sorry that I can't help bisecting it.

runs away

[fzurita]

So in two devices so far, I can't reproduce the issue, they are Mali and Adreno devices. I do have a PowerVR device to try as well. Hopefully I see it there.

[m4xw]

Some Mali devices seem affected tho libretro/mupen64plus-libretro-nx#99 (comment)

I have to rebuild a RPi2/3 image will then check & report again. But since I had these glitches on a Khadas VIM, VIM 3 & RockPro64 which use a Mali 450, T860 & G52 I suspect it's related to them.

Fwiw it was reported with no issues on RPi

Just tested on RPI3B+ with KMS/DRM/GLES2 using latest develop branch and all default core options, all looks normal here.

[m4xw]

Also some amlogic devices. (cant remember what they use, I think mali too?)

Here was another Mali:

I used an Android TV Box, MX3-G S912, Open GL 2.0ES and Mali 450.

Broke like this:

[m4xw]

@fzurita You are testing latest master right now?
Or the commit gonetz asked?

[fzurita]

Latest master

[m4xw]

Dunno if he changed smth but when I asked people to test my experimental branch (which was what gonetz just rebased), same issues appeared..
hm...

Try this commit 2d712f2
And cherry pick 34c6cae

[m4xw]

btw are you testing GLES2 or GLES3?
I got mixed reports in that regard..

[fzurita]

GLES3, I have some devices with GLES2.0 to test with, so I'll try those next.

[m4xw]

Someone said GLES3 somewhat fixed it on his Mali, others reported no benefit.
Might also be related to a few option combos.

[m4xw]

A quick reminder how it ended up for amlogic https://www.youtube.com/watch?v=6oYoRE0gkFw

[GranvilleR]

In the Libretro core, the first time I booted a game it worked correctly. I had to close and reload the content to trigger the most serious glitches (like the missing graphics in Mario 64 seen in the first post). I haven't tested the issue in Mupen FZ to know how to trigger it there. Using a Galaxy S10 Adreno.

[m4xw]

Yea that was the shadercache issue.

[fzurita]

Was the shader cache issue a libretro only issue?

[m4xw]

I can't tell you that.
However we let GLN64 handle that completely, don't have any logic there that diverges from upstream.

[m4xw]

Doesn't happen on mupen fz?

[m4xw]

@fzurita btw my rebase was done on this directly:

I'd really test that commit to exclude a later fix if you have trouble reproducing it.
Also make sure to test the shader cache, I don't think that would be libretro exclusive and might be the actual cause of these severe bugs.

[fzurita]

I'm not seeing the issue in mupen64plus FZ with at least 3 different phones.

[m4xw]

On that commit?

[fzurita]

Latest master.

[m4xw]

Try that commit please, so we can exclude a later fix.
If we know it happened there and not later, would help a lot already.

[gonetz]

@Panderner fix is done. Please test again.

[drinfernoo]

I've tested builds of the core from @m4xw, and I'm not seeing any improvement on my end.

[m4xw]

@drinfernoo Your issue might be unrelated.
Will need shanti to confirm it.

[m4xw]

Shanti quickly confirmed the fix for MK64 from remote, he will do more throughout testing later.
So yea that GLES2 issue is very likely fixed.
Still no idea what ghosts hunt drinfernoo's shield.

[fzurita]

@drinfernoo it sounds like you have a different issue. Do you have a Nvidia shield tv? Is your problem only with the libretro core?

[Panderner]

@gonetz where is the build?

[drinfernoo]

@fzurita Yes and yes. FZ works fine.

[fzurita]

Ok, I have a Nvidia shield tv. I'll check what is happening and whether it's related to GLideN64.

[gonetz]

@gonetz where is the build?

Where did you get it for the first time?
Sources updated, so binaries should be updated too.

[fzurita]

Shader cache definitely breaks the shield tv with the libretro core. It works fine on mupen64plus fz. The problem is probably in the libretro core and not the video plug-in.

This issue should probably close.

[gonetz]

As I understand, we did everything we could do on our side.
Lets close it then.

[m4xw]

Ye the libretro issue is only semi related, basically your changes broke some of my GL state machine logic (which should never happen to begin with).
But my glsm version does some pretty funky stuff to begin with, just wasn't a issue before your recent updates.
So, yea. It's my homework not yours ;)

[Panderner]

@gonetz glideN64 still not fixed and updated

[gonetz]

@Panderner fzurita says that GLideN64 works fine on mupen64plus fz.
Can we do anything on our side to make it working better on Libretro mupen64plus?

[m4xw]

@gonetz No need to do anything from your part, in regards to libretro.
I first need to understand what actually triggered the Issue in my codebase.
fwiw some issues only seem to appear at lowest resolution only.

[Panderner]

Still not fixed I'm using realme C2, the mupen64plus fz and libretro mupen64plus didn't update glideN64 and still corrupted

[fzurita]

@Panderner So does it work with Mupen64Plus FZ for you but not with libretro?

[Panderner]

Even gliden64 fast, medium, accurate, and very accurate, glitched out

[fzurita]

This is a completely different problem between libretro and mupen64plus fz. Please open a new issue that only describes the problem in mupen64plus fz.

[m4xw]

@fzurita We don't have any of these configurations, he must be talking about fz.

[m4xw]

@gonetz Just a headsup, this issue isn't fixed, I found the cause and it does indeed affect mupen fz and mupen next, only at lowest resolution (< 640x580).
I default to 320x240, hence I got so many reports and was still never able to reproduce it, heh.
tldr of it is: You mixed some logic realH/W and width/height do and your changes break your own design completely.
You used to set realWidth etc, do the buffer size calc and then you overwrote it later, now it's all the same and it tries to blit a 640x580 texture onto a 320x240 fb (instead of x298 anyway, due to just picking DisplayWindow sizes).
A simple mitigation @fzurita suggested is setting nativeResFactor to 1 and that does indeed work, but scaled now ofc.

Dunno if you want to deprecate it or it was a oversight.
This is likely also related to #2102, as well:
libretro/mupen64plus-libretro-nx#109
libretro/mupen64plus-libretro-nx#108
libretro/mupen64plus-libretro-nx#98

and maaaybe:
libretro/mupen64plus-libretro-nx#119
libretro/mupen64plus-libretro-nx#112

I will write a Issue about that & the details sometime tomorrow.

[m4xw]

However I believe the specific issue Panderner had, is something completely different tho.

[fzurita]

Yeah, I created this issue for Panderner's issues: #2108

[gonetz]

It is very strange decision to set default to 320x240 for N64 games, because half of them use higher internal resolution. The plugin designed to work in high or at least native resolutions, not in resolutions below native.
The fzurita's suggestion to set nativeResFactor to 1 should work indeed. I tested hi-res N64 games such as Indi in 320x240 resolution with native-res enabled and found no issues. What "scaled now ofc" means?

[m4xw]

@gonetz This is a bit of a unexpected response, since it used to work before your changes.

The plugin designed to work in high or at least native resolutions, not in resolutions below native.

So I must assume it was unknowingly working?

320x (no nativeResFactor, no longer working)

320x (with nativeResFactor)

With scaling I mean the scale factor calculations that are applied in your blitting logic, but I guess, the pics tell it already.

Also thats one of the cases where you broke the logic that worked prior:

Notice the ->width etc override, I confirmed that with my setup it would override them to 320x298
So, what does GLideN want going forward?

[gonetz]

So I must assume it was unknowingly working?

I did not know that it might work that way. It is really wrong idea to have rendering buffer smaller than frame buffer in RDRAM.

Also thats one of the cases where you broke the logic that worked prior:

It was major refactoring, and I really could made mistakes. This change looks as a mistake.
However, I can't see how it is related to the original issue. Could you open a new issue with whole details about what is wrong and when (and why) things got broken?

So, what does GLideN want going forward?

I'm not sure that I understand that question.

[m4xw]

(just a quick reminder i didnt forget to create the issue, but I didn't have time to investigate some more, for creating a detailed bug report).
Hope I get to it on the holidays.