N64 blending emulation #970

Closed
gonetz opened this Issue Apr 24, 2016 · 88 comments

Comments

Projects
None yet
8 participants
@gonetz
Owner

gonetz commented Apr 24, 2016

Goal: implement emulation of N64 blending modes with minimal hacks and heuristics.

Explanation:

Blending is a part of pixel pipeline. Color of incoming pixel interpolated with color of pixel in buffer to achieve various effects, mainly transparency.
Blending process on N64 also blends incoming and stored colors, but not only that. N64 blending also can mix incoming color with two constant colors: fog color and blend color. This is used mainly to apply fog, but creative programmers used that option as additional stage of color combiner. Standard OpenGL blending is good enough to blend pixel and memory colors, but when it is first necessary to mix input color with constant colors, it fails.

OpenGL blending is part of fixed functionality. Shaders cannot use blending. There are GL extensions, which actually allowed blending in shaders, but only when several conditions met. Shader-based blending is hardly possible with N64 emulation. Thus, currently GLideN64 uses legacy glN64 blending method. The correspondence between N64 blending modes and OpenGL ones is hardcoded. If blending mode mixes input color with constant colors, it is emulated in shader with special code.

New blending uses general method of blending emulation. No more hardcoded blending modes. All special code in shaders replaced by general blending functions. Note that it is not true “shader blending”. New method uses standard one-pass OpenGL blending with no extensions. It will work on all supported hardware without performance sacrifices. From the other side, shader can’t blend input color with memory color. Usually it is not necessary because standard blending will do the job. However, some crazy blend modes will probably left unemulated.

New blending resides in experimental_blend feature branch. Binary to test:
https://drive.google.com/file/d/0B0YqMPjGo3B2azZuTG9jX3pEaEU/view?usp=sharing
Visually there should be no difference with master in 99.9% of cases. Please report about regressions in that ticket, not open a new one.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 24, 2016

Contributor

Looks to me like you've already squashed some bugs.

F-Zero X seems to have black borders on ships and specular now. I could be wrong, though.
gliden64_f-zero_x_001

World Driver Championship reflections seem to be fixed.
gliden64_world_driver_champ_005

Contributor

AmbientMalice commented Apr 24, 2016

Looks to me like you've already squashed some bugs.

F-Zero X seems to have black borders on ships and specular now. I could be wrong, though.
gliden64_f-zero_x_001

World Driver Championship reflections seem to be fixed.
gliden64_world_driver_champ_005

@gonetz gonetz referenced this issue Apr 24, 2016

Closed

WIP builds. #885

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 24, 2016

Owner

F-Zero X seems to have black borders and specular now. I could be wrong, though.

Yep, but ingame cars are broken :(

Owner

gonetz commented Apr 24, 2016

F-Zero X seems to have black borders and specular now. I could be wrong, though.

Yep, but ingame cars are broken :(

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Apr 24, 2016

Was not the lights deactivated for this game? I thought it was a microcode issue, not blending

olivieryuyu commented Apr 24, 2016

Was not the lights deactivated for this game? I thought it was a microcode issue, not blending

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 24, 2016

Owner

Was not the lights deaxtivated for this game?

F-Zero? No, it uses lighting. As I remember, there was a problem with specular reflection.
BTW, blending works ok in LLE mode. Looks like HLE issue.

Owner

gonetz commented Apr 24, 2016

Was not the lights deaxtivated for this game?

F-Zero? No, it uses lighting. As I remember, there was a problem with specular reflection.
BTW, blending works ok in LLE mode. Looks like HLE issue.

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Apr 24, 2016

If I remember correctly, you have deactivated a long time ago something for the reflections for this game.

if (strncmp(&uc_str[14], "F3DF", 4) == 0)
current.textureGen = false;

May be not related however, dunno

olivieryuyu commented Apr 24, 2016

If I remember correctly, you have deactivated a long time ago something for the reflections for this game.

if (strncmp(&uc_str[14], "F3DF", 4) == 0)
current.textureGen = false;

May be not related however, dunno

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

#481 seems to be fixed. Fade to white looks smooth.
#688 seems to be fixed.

Contributor

AmbientMalice commented Apr 25, 2016

#481 seems to be fixed. Fade to white looks smooth.
#688 seems to be fixed.

@ADormant
@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

@ADormant why do you think it will help me? Have you checked these links yourself?

Owner

gonetz commented Apr 25, 2016

@ADormant why do you think it will help me? Have you checked these links yourself?

@ADormant

This comment has been minimized.

Show comment
Hide comment
@ADormant

ADormant Apr 25, 2016

Are texture barrier and shader interlock working with N64 blending?
PPSSPP has shader blending.

ADormant commented Apr 25, 2016

Are texture barrier and shader interlock working with N64 blending?
PPSSPP has shader blending.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

I don't use them.

Owner

gonetz commented Apr 25, 2016

I don't use them.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

Why not?

Owner

gonetz commented Apr 25, 2016

Why not?

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

I explained possible issue with this method.
Nobody proved yet that this possible issue actually resulted as graphics glitch.
Nobody proved yet that GL extensions you mentioned are applicable for N64 emulation.
If you really want to help, learn the links you provided and suggest a way how to improve my code.
Or at least find a case, where new blending emulation fails.

Owner

gonetz commented Apr 25, 2016

I explained possible issue with this method.
Nobody proved yet that this possible issue actually resulted as graphics glitch.
Nobody proved yet that GL extensions you mentioned are applicable for N64 emulation.
If you really want to help, learn the links you provided and suggest a way how to improve my code.
Or at least find a case, where new blending emulation fails.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

if (strncmp(&uc_str[14], "F3DF", 4) == 0) current.textureGen = false;

This disables specular reflection, not lighting. F3DF is F-Zero ucode, true.

Owner

gonetz commented Apr 25, 2016

if (strncmp(&uc_str[14], "F3DF", 4) == 0) current.textureGen = false;

This disables specular reflection, not lighting. F3DF is F-Zero ucode, true.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

Vigilante 8 no longer misbehaves when looking directly at lens flares.

@ADormant I think Gonetz may be right. Using shaders for blending is probably putting the cart before the horse if there aren't any known issues with fixed function. It ends up being technology for the sake of technology.

Contributor

AmbientMalice commented Apr 25, 2016

Vigilante 8 no longer misbehaves when looking directly at lens flares.

@ADormant I think Gonetz may be right. Using shaders for blending is probably putting the cart before the horse if there aren't any known issues with fixed function. It ends up being technology for the sake of technology.

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Apr 25, 2016

Having tested the new blending, i cannot see new bugs, only improvments, except this F-Zero but this is peculiar game with something specific in HLE.

olivieryuyu commented Apr 25, 2016

Having tested the new blending, i cannot see new bugs, only improvments, except this F-Zero but this is peculiar game with something specific in HLE.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

@olivieryuyu good to know, thanks!

Owner

gonetz commented Apr 25, 2016

@olivieryuyu good to know, thanks!

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

More improvements:
Donald Duck: background has correct color hue now.
ISS 64: shadows look correct now - solid with right transparency level. The game needs N64 depth compare enabled.

Owner

gonetz commented Apr 25, 2016

More improvements:
Donald Duck: background has correct color hue now.
ISS 64: shadows look correct now - solid with right transparency level. The game needs N64 depth compare enabled.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

I've found what seems to be a regression. If you load a game, and turn Aux FB to RAM on and then off, it breaks transparencies. They stay broken until emulation is reset. It's very obvious in Extreme-G, with the flares from the vehicles.

gliden64_turok_3 _shadow_of_o_000

Contributor

AmbientMalice commented Apr 25, 2016

I've found what seems to be a regression. If you load a game, and turn Aux FB to RAM on and then off, it breaks transparencies. They stay broken until emulation is reset. It's very obvious in Extreme-G, with the flares from the vehicles.

gliden64_turok_3 _shadow_of_o_000

@olivieryuyu

This comment has been minimized.

Show comment
Hide comment
@olivieryuyu

olivieryuyu Apr 25, 2016

@AmbientMalice

#688 seems to be fixed?

I cannot see that.

You may compare with Angrylion plugin.

olivieryuyu commented Apr 25, 2016

@AmbientMalice

#688 seems to be fixed?

I cannot see that.

You may compare with Angrylion plugin.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

GLideN64
gliden64_hexen_003
Angrylion's
nhxe0000 2

Contributor

AmbientMalice commented Apr 25, 2016

GLideN64
gliden64_hexen_003
Angrylion's
nhxe0000 2

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

This behavior seems new.

HLE:
gliden64_turok_3 _shadow_of_o_002
LLE:
gliden64_turok_3 _shadow_of_o_003

In addition, most of the geometry is missing with the thermal goggles in LLE mode now.

Contributor

AmbientMalice commented Apr 25, 2016

This behavior seems new.

HLE:
gliden64_turok_3 _shadow_of_o_002
LLE:
gliden64_turok_3 _shadow_of_o_003

In addition, most of the geometry is missing with the thermal goggles in LLE mode now.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

@AmbientMalice savestate please.

Owner

gonetz commented Apr 25, 2016

@AmbientMalice savestate please.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

Extreme-G:
http://s000.tinyupload.com/index.php?file_id=27632938566080491951
Random elements will become buggy when turning Aux FB on and off. Dust trails from zig-zagging can become triangular. Vehicle lights can break. 2D weapon elements can break. Annoyingly, the corruption is very random. I'm not 100% sure it's caused by this branch, but today is the first time I noticed it.

Turok 3:
http://s000.tinyupload.com/?file_id=02433454240150271099
Light texture disappears in LLE mode.

Contributor

AmbientMalice commented Apr 25, 2016

Extreme-G:
http://s000.tinyupload.com/index.php?file_id=27632938566080491951
Random elements will become buggy when turning Aux FB on and off. Dust trails from zig-zagging can become triangular. Vehicle lights can break. 2D weapon elements can break. Annoyingly, the corruption is very random. I'm not 100% sure it's caused by this branch, but today is the first time I noticed it.

Turok 3:
http://s000.tinyupload.com/?file_id=02433454240150271099
Light texture disappears in LLE mode.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 25, 2016

Owner

Can't load the saves. Could you make PJ64 2.2 compatible saves?

Owner

gonetz commented Apr 25, 2016

Can't load the saves. Could you make PJ64 2.2 compatible saves?

@oddMLan

This comment has been minimized.

Show comment
Hide comment
@oddMLan

oddMLan Apr 25, 2016

Contributor

Keep in mind that Project64 2.2 is bugged now. You ought to load the game, press F5 to make an instant save, press F7 to load it and THEN load your external savestate. EDIT: FIXED IN LATEST BUILDS.

I just tested the Extreme-G savestate AmbientMalice uploaded, it loads succesfully following this workaround. project64/project64#1032

EDIT: @gonetz
The issue with Project64 got fixed in one of the recent code cleanups/rewrites. You should compile the latest master to avoid further issues with savestates

Contributor

oddMLan commented Apr 25, 2016

Keep in mind that Project64 2.2 is bugged now. You ought to load the game, press F5 to make an instant save, press F7 to load it and THEN load your external savestate. EDIT: FIXED IN LATEST BUILDS.

I just tested the Extreme-G savestate AmbientMalice uploaded, it loads succesfully following this workaround. project64/project64#1032

EDIT: @gonetz
The issue with Project64 got fixed in one of the recent code cleanups/rewrites. You should compile the latest master to avoid further issues with savestates

@LegendOfDragoon

This comment has been minimized.

Show comment
Hide comment
@LegendOfDragoon

LegendOfDragoon Apr 25, 2016

You ought to load the game, press F5 to make an instant save, press F7 to load it and THEN load your external savestate.

What problem does Pj64 have, that requires you to do something like this?

You ought to load the game, press F5 to make an instant save, press F7 to load it and THEN load your external savestate.

What problem does Pj64 have, that requires you to do something like this?

@oddMLan

This comment has been minimized.

Show comment
Hide comment
@oddMLan

oddMLan Apr 25, 2016

Contributor

EDIT: The aforementioned bug with the savestates was fixed.

Tested a bunch of games and so far I thought I found a regression in DK64, but it turns out I forgot to delete the shader cache 😁

Contributor

oddMLan commented Apr 25, 2016

EDIT: The aforementioned bug with the savestates was fixed.

Tested a bunch of games and so far I thought I found a regression in DK64, but it turns out I forgot to delete the shader cache 😁

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 25, 2016

Contributor

Can't load the saves. Could you make PJ64 2.2 compatible saves?

I'll see what I can do. I haven't used 2.2 in quite some time because it tends to BSOD my PC, even with Win 7 compatibility mode.

Contributor

AmbientMalice commented Apr 25, 2016

Can't load the saves. Could you make PJ64 2.2 compatible saves?

I'll see what I can do. I haven't used 2.2 in quite some time because it tends to BSOD my PC, even with Win 7 compatibility mode.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

What about 2.0? 1.6 saves also OK for me.
I have large collection of saves, which are compatible between older versions of PJ64, but saves from latest builds work only with it.

Owner

gonetz commented Apr 26, 2016

What about 2.0? 1.6 saves also OK for me.
I have large collection of saves, which are compatible between older versions of PJ64, but saves from latest builds work only with it.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 26, 2016

Contributor

What about 2.0?

The BSOD problem was introduced before 2.0, and was fixed after 2.2 I believe save state backwards compatibility was accidentally broken after 64DD support was added.

Contributor

AmbientMalice commented Apr 26, 2016

What about 2.0?

The BSOD problem was introduced before 2.0, and was fixed after 2.2 I believe save state backwards compatibility was accidentally broken after 64DD support was added.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

Ok, Turok issue fixed, DK64 issue fixed by itself. @AmbientMalice is the bug with aux copy and extreme g still exists? I can't reproduce it.

Owner

gonetz commented Apr 26, 2016

Ok, Turok issue fixed, DK64 issue fixed by itself. @AmbientMalice is the bug with aux copy and extreme g still exists? I can't reproduce it.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 26, 2016

Contributor

@AmbientMalice is the bug with aux copy and extreme g still exists? I can't reproduce it.

I'll test some more later, and if I can find a case of it happening, I'll try to find a reliable one. It seems very fickle.

Contributor

AmbientMalice commented Apr 26, 2016

@AmbientMalice is the bug with aux copy and extreme g still exists? I can't reproduce it.

I'll test some more later, and if I can find a case of it happening, I'll try to find a reliable one. It seems very fickle.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

Tested a bunch of games and so far I thought I found a regression in DK64, but it turns out I forgot to delete the shader cache

That is strange actually. I changed shader cache version, so old cache should not load.

Owner

gonetz commented Apr 26, 2016

Tested a bunch of games and so far I thought I found a regression in DK64, but it turns out I forgot to delete the shader cache

That is strange actually. I changed shader cache version, so old cache should not load.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

I built GLideN64 for Zilmar using the GLideNUI from the other thread.

Bad idea. I changed config.h, old lib will not work correct.

I posted updated binary yesterday:
https://drive.google.com/file/d/0B0YqMPjGo3B2eWkyZEJCampjR2c/view?usp=sharing

Owner

gonetz commented Apr 26, 2016

I built GLideN64 for Zilmar using the GLideNUI from the other thread.

Bad idea. I changed config.h, old lib will not work correct.

I posted updated binary yesterday:
https://drive.google.com/file/d/0B0YqMPjGo3B2eWkyZEJCampjR2c/view?usp=sharing

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice Apr 26, 2016

Contributor

@gonetz Thanks. I notice LLE fog is fixed, which is very nice. #384

Contributor

AmbientMalice commented Apr 26, 2016

@gonetz Thanks. I notice LLE fog is fixed, which is very nice. #384

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

Yes, nice bonus.

Owner

gonetz commented Apr 26, 2016

Yes, nice bonus.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 26, 2016

Owner

All reported bugs seems to be fixed (except unconfirmed issue with aux copy on/off).
The only thing left is to fix GLES2 support.

Owner

gonetz commented Apr 26, 2016

All reported bugs seems to be fixed (except unconfirmed issue with aux copy on/off).
The only thing left is to fix GLES2 support.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 29, 2016

Owner

After two days of debugging I finally found what causes crash with GLES3 build. It took so long because it crashes somewhere inside gl drivers and I got no errors on app level. Also, the problem could disappear when I removed part of code, which, as I found later, absolutely unrelated to the problem. I'm not sure what exactly happened because I don't have driver sources. I think, it is optimization issue. Shader compiler removes unused variables. If you declare uniform variable, but not use it in the code, compiler will not include that variable into shader program. I declared uniform vector of size 2. For 1cycle combiner the shader uses only first element of the vector. Looks like compiler allocates place only for one element of the vector, and when I update the variable with glUniform2i, gl crashes. I did not expect that from NVidia.

Owner

gonetz commented Apr 29, 2016

After two days of debugging I finally found what causes crash with GLES3 build. It took so long because it crashes somewhere inside gl drivers and I got no errors on app level. Also, the problem could disappear when I removed part of code, which, as I found later, absolutely unrelated to the problem. I'm not sure what exactly happened because I don't have driver sources. I think, it is optimization issue. Shader compiler removes unused variables. If you declare uniform variable, but not use it in the code, compiler will not include that variable into shader program. I declared uniform vector of size 2. For 1cycle combiner the shader uses only first element of the vector. Looks like compiler allocates place only for one element of the vector, and when I update the variable with glUniform2i, gl crashes. I did not expect that from NVidia.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 30, 2016

Owner

@fzurita I have fixed issues with post-processor and GLES2. I have tested it on my device with Adreno 330 gpu, no new issues.

I think the feature is ready to land.

Owner

gonetz commented Apr 30, 2016

@fzurita I have fixed issues with post-processor and GLES2. I have tested it on my device with Adreno 330 gpu, no new issues.

I think the feature is ready to land.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita Apr 30, 2016

Contributor

Majora's Mask still gives me issues with GLES 3.0. This issue doesn't happen with the master branch.

Contributor

fzurita commented Apr 30, 2016

Majora's Mask still gives me issues with GLES 3.0. This issue doesn't happen with the master branch.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 30, 2016

Owner

Probably different drivers version.

Owner

gonetz commented Apr 30, 2016

Probably different drivers version.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita Apr 30, 2016

Contributor

I'll throw some debugging in later to figure out which piece of code is causing issues.

Contributor

fzurita commented Apr 30, 2016

I'll throw some debugging in later to figure out which piece of code is causing issues.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz Apr 30, 2016

Owner

I hope you will find a solution once again :)

Owner

gonetz commented Apr 30, 2016

I hope you will find a solution once again :)

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 1, 2016

Contributor

I was able to track down the issue to this call in Shaders_ogl3x.h in the snoise method.

" return texelFetch(uTexNoise, coord, 0).r; \n"

Given that this is only used when noise emulation is enabled. I tried turning off noise emulation and all issues in OpenGL ES 3.0 go away. Curiously, you did not change this in this branch, although, if I go back to the master branch the issue also goes away.

Edit 1: Replacing

ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale);

with

ivec2 coord = ivec2(gl_FragCoord.xy);

in that same snoise method also fixes the issue, leading me to suspect that uScreenScale doesn't have a good value. I noticed that this gets set differently depending on whether native resolution is on/off but changing that doesn't fix the issue.

Edit 2: Setting the native resolution factor to 1 should definitely work, but it doesn't.

Edit 3: Changing the snoise method to this also fixes it:

"lowp float snoise()                                    \n"
"{                                                      \n"
//"  ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale); \n"
"  mediump vec2 uScreenScale2; \n"
"  uScreenScale2.x = clamp(uScreenScale.x, 0.0, 5.0); \n"
"  uScreenScale2.y = clamp(uScreenScale.y, 0.0, 5.0); \n"
"  ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale2);  \n"
"  return texelFetch(uTexNoise, coord, 0).r;            \n"
"}                                                      \n"

It tells me that somehow uScreenScale is getting a junk value. I tried setting uScreenScale to 1.0, 1.0 manually and commenting all code that updates it and it's still getting a junk value as well. Also glGetUniformLocation is returning a good value for it.

Contributor

fzurita commented May 1, 2016

I was able to track down the issue to this call in Shaders_ogl3x.h in the snoise method.

" return texelFetch(uTexNoise, coord, 0).r; \n"

Given that this is only used when noise emulation is enabled. I tried turning off noise emulation and all issues in OpenGL ES 3.0 go away. Curiously, you did not change this in this branch, although, if I go back to the master branch the issue also goes away.

Edit 1: Replacing

ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale);

with

ivec2 coord = ivec2(gl_FragCoord.xy);

in that same snoise method also fixes the issue, leading me to suspect that uScreenScale doesn't have a good value. I noticed that this gets set differently depending on whether native resolution is on/off but changing that doesn't fix the issue.

Edit 2: Setting the native resolution factor to 1 should definitely work, but it doesn't.

Edit 3: Changing the snoise method to this also fixes it:

"lowp float snoise()                                    \n"
"{                                                      \n"
//"  ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale); \n"
"  mediump vec2 uScreenScale2; \n"
"  uScreenScale2.x = clamp(uScreenScale.x, 0.0, 5.0); \n"
"  uScreenScale2.y = clamp(uScreenScale.y, 0.0, 5.0); \n"
"  ivec2 coord = ivec2(gl_FragCoord.xy/uScreenScale2);  \n"
"  return texelFetch(uTexNoise, coord, 0).r;            \n"
"}                                                      \n"

It tells me that somehow uScreenScale is getting a junk value. I tried setting uScreenScale to 1.0, 1.0 manually and commenting all code that updates it and it's still getting a junk value as well. Also glGetUniformLocation is returning a good value for it.

@AmbientMalice

This comment has been minimized.

Show comment
Hide comment
@AmbientMalice

AmbientMalice May 2, 2016

Contributor

@fzurita Maybe #958 is related?

Contributor

AmbientMalice commented May 2, 2016

@fzurita Maybe #958 is related?

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 2, 2016

Contributor

It's possible, but it's only causing a display driver crash on my device, which is what I'm seeing and trying to debug here.

Contributor

fzurita commented May 2, 2016

It's possible, but it's only causing a display driver crash on my device, which is what I'm seeing and trying to debug here.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 2, 2016

Owner

It can be induced issues, as with my recent experience with debug for NVidia Shield:
#970 (comment)
I had a crash in Zelda OOT. When I removed alpha dithering, game stopped to crash. I found real problem by chance: adb log contained stack trace after crash, which says that crash happened in gl function glUniform2i. That is, no issue with shader compile or link. Shader did not crash without alpha dithering code, but most likely it did not work correct either. Can you check adb log for clues after game crash?

Owner

gonetz commented May 2, 2016

It can be induced issues, as with my recent experience with debug for NVidia Shield:
#970 (comment)
I had a crash in Zelda OOT. When I removed alpha dithering, game stopped to crash. I found real problem by chance: adb log contained stack trace after crash, which says that crash happened in gl function glUniform2i. That is, no issue with shader compile or link. Shader did not crash without alpha dithering code, but most likely it did not work correct either. Can you check adb log for clues after game crash?

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 2, 2016

Contributor

Shader compilation and link work just fine. I do get logs when the driver crashes but they are very cryptic:

04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0x400c0907 (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha E/Adreno-ES20: <rb_timestamp_wait_on_timestamp:341>: gsl_device_waittimestamp failed in rb_timestamp_wait_on_timestamp
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-EGL: <eglTimestampCreate:5600>: EGL_CONTEXT_LOST

And the crash only happens when we send a bad value (due to bad uScreenScale value) for the coord to texelFetch

Contributor

fzurita commented May 2, 2016

Shader compilation and link work just fine. I do get logs when the driver crashes but they are very cryptic:

04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0x400c0907 (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha E/Adreno-ES20: <rb_timestamp_wait_on_timestamp:341>: gsl_device_waittimestamp failed in rb_timestamp_wait_on_timestamp
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-EGL: <eglTimestampCreate:5600>: EGL_CONTEXT_LOST

And the crash only happens when we send a bad value (due to bad uScreenScale value) for the coord to texelFetch

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

These logs won't help :(
Could you log GL version string? I wonder, why that code works ok on my device.

Owner

gonetz commented May 3, 2016

These logs won't help :(
Could you log GL version string? I wonder, why that code works ok on my device.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

Here you go:

05-02 23:29:32.048 12458-12546/org.mupen64plusae.v3.alpha I/Adreno-EGL: <qeglDrvAPI_eglInitialize:410>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_LA.BF.1.1.1_RB1.05.00.02.042.016_msm8974_LA.BF.1.1.1_RB1__release_AU ()
                                                                        OpenGL ES Shader Compiler Version: E031.25.03.00
                                                                        Build Date: 02/11/15 Wed
                                                                        Local Branch: mybranch7539026
                                                                        Remote Branch: quic/LA.BF.1.1.1_rb1.10
                                                                        Local Patches: NONE
                                                                        Reconstruct Branch: AU_LINUX_ANDROID_LA.BF.1.1.1_RB1.05.00.02.042.016 + 62ca4eb + acd831d + 9f8b442 + e027a02 + cba30ba + 53c303a + a649d79 + 23e16f8 + 5e97da7 + cbd2a44 + 33d072a + 7aacf06 + 72b33e7 + 28f6f60 + b4c13d8 +  NOTHING
05-02 23:29:32.053 12458-12546/org.mupen64plusae.v3.alpha I/OpenGLRenderer: Initialized EGL, version 1.4

What does your Adreno driver version look like?

Contributor

fzurita commented May 3, 2016

Here you go:

05-02 23:29:32.048 12458-12546/org.mupen64plusae.v3.alpha I/Adreno-EGL: <qeglDrvAPI_eglInitialize:410>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_LA.BF.1.1.1_RB1.05.00.02.042.016_msm8974_LA.BF.1.1.1_RB1__release_AU ()
                                                                        OpenGL ES Shader Compiler Version: E031.25.03.00
                                                                        Build Date: 02/11/15 Wed
                                                                        Local Branch: mybranch7539026
                                                                        Remote Branch: quic/LA.BF.1.1.1_rb1.10
                                                                        Local Patches: NONE
                                                                        Reconstruct Branch: AU_LINUX_ANDROID_LA.BF.1.1.1_RB1.05.00.02.042.016 + 62ca4eb + acd831d + 9f8b442 + e027a02 + cba30ba + 53c303a + a649d79 + 23e16f8 + 5e97da7 + cbd2a44 + 33d072a + 7aacf06 + 72b33e7 + 28f6f60 + b4c13d8 +  NOTHING
05-02 23:29:32.053 12458-12546/org.mupen64plusae.v3.alpha I/OpenGLRenderer: Initialized EGL, version 1.4

What does your Adreno driver version look like?

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

So, I'm testing more games. Most games seem to be broken. The only difference in the shader program for games that work and that don't work is that the ones that don't work have this extra:


  if (uForceBlendCycle2 != 0) {             
    muxPM[0] = vec4(color2, alpha2);            
    muxA[0] = alpha2;                           
    muxB[0] = 1.0 - muxA[uBlendMux2[1]];        
    lowp vec4 blend2 = muxPM[uBlendMux2[0]] * muxA[uBlendMux2[1]] + muxPM[uBlendMux2[2]] * muxB[uBlendMux2[3]]; 
    color2 = clamp(blend2.rgb, 0.0, 1.0);       
  } 

Edit 1: so after commenting this piece of code out, uScreenScale has a valid value and the display driver stops crashing.

Contributor

fzurita commented May 3, 2016

So, I'm testing more games. Most games seem to be broken. The only difference in the shader program for games that work and that don't work is that the ones that don't work have this extra:


  if (uForceBlendCycle2 != 0) {             
    muxPM[0] = vec4(color2, alpha2);            
    muxA[0] = alpha2;                           
    muxB[0] = 1.0 - muxA[uBlendMux2[1]];        
    lowp vec4 blend2 = muxPM[uBlendMux2[0]] * muxA[uBlendMux2[1]] + muxPM[uBlendMux2[2]] * muxB[uBlendMux2[3]]; 
    color2 = clamp(blend2.rgb, 0.0, 1.0);       
  } 

Edit 1: so after commenting this piece of code out, uScreenScale has a valid value and the display driver stops crashing.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

My drivers are older:

05-03 16:03:11.560: I/Adreno-EGL(16208): <qeglDrvAPI_eglInitialize:410>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_LA.BF.1.1_RB1.05.00.00.002.025_msm8974_LA.BF.1.1_RB1__release_AU ()
05-03 16:03:11.560: I/Adreno-EGL(16208): OpenGL ES Shader Compiler Version: E031.25.01.03
05-03 16:03:11.560: I/Adreno-EGL(16208): Build Date: 11/19/14 Wed
05-03 16:03:11.560: I/Adreno-EGL(16208): Local Branch: mybranch5813579
05-03 16:03:11.560: I/Adreno-EGL(16208): Remote Branch: quic/LA.BF.1.1_rb1.11
05-03 16:03:11.560: I/Adreno-EGL(16208): Local Patches: NONE
05-03 16:03:11.560: I/Adreno-EGL(16208): Reconstruct Branch: AU_LINUX_ANDROID_LA.BF.1.1_RB1.05.00.00.002.025 + 30e7589 +  NOTHING
05-03 16:03:11.560: I/OpenGLRenderer(16208): Initialized EGL, version 1.4

so after commenting this piece of code out, uScreenScale has a valid value and the display driver stops crashing.

As I thought, the issue with uScreenScale is induced by an issue in new code. That code

if (uForceBlendCycle2 != 0) { 
}

is part of new blending. It is 2nd cycle of the blending, for 2cycle mode combiners.
I don't see anything suspicious in that part of code though.

Owner

gonetz commented May 3, 2016

My drivers are older:

05-03 16:03:11.560: I/Adreno-EGL(16208): <qeglDrvAPI_eglInitialize:410>: EGL 1.4 QUALCOMM build: AU_LINUX_ANDROID_LA.BF.1.1_RB1.05.00.00.002.025_msm8974_LA.BF.1.1_RB1__release_AU ()
05-03 16:03:11.560: I/Adreno-EGL(16208): OpenGL ES Shader Compiler Version: E031.25.01.03
05-03 16:03:11.560: I/Adreno-EGL(16208): Build Date: 11/19/14 Wed
05-03 16:03:11.560: I/Adreno-EGL(16208): Local Branch: mybranch5813579
05-03 16:03:11.560: I/Adreno-EGL(16208): Remote Branch: quic/LA.BF.1.1_rb1.11
05-03 16:03:11.560: I/Adreno-EGL(16208): Local Patches: NONE
05-03 16:03:11.560: I/Adreno-EGL(16208): Reconstruct Branch: AU_LINUX_ANDROID_LA.BF.1.1_RB1.05.00.00.002.025 + 30e7589 +  NOTHING
05-03 16:03:11.560: I/OpenGLRenderer(16208): Initialized EGL, version 1.4

so after commenting this piece of code out, uScreenScale has a valid value and the display driver stops crashing.

As I thought, the issue with uScreenScale is induced by an issue in new code. That code

if (uForceBlendCycle2 != 0) { 
}

is part of new blending. It is 2nd cycle of the blending, for 2cycle mode combiners.
I don't see anything suspicious in that part of code though.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

It's probably a driver bug... I just have to find a workaround. It seems that in the new code you started treating a vec4 as an array. Maybe it doesn't like that.

Contributor

fzurita commented May 3, 2016

It's probably a driver bug... I just have to find a workaround. It seems that in the new code you started treating a vec4 as an array. Maybe it doesn't like that.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

@fzurita I found an issue with my code: cycle2 specific code added for cycle_copy and cycle_fill modes. It could cause an issue. Please apply my patch 638a416 and check again.

Owner

gonetz commented May 3, 2016

@fzurita I found an issue with my code: cycle2 specific code added for cycle_copy and cycle_fill modes. It could cause an issue. Please apply my patch 638a416 and check again.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

Nope, didn't fix it.

Contributor

fzurita commented May 3, 2016

Nope, didn't fix it.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

:( No more ideas yet

Owner

gonetz commented May 3, 2016

:( No more ideas yet

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

BTW, have you cleared shader cache?

Owner

gonetz commented May 3, 2016

BTW, have you cleared shader cache?

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

Yeah, I have had it disabled for this testing.

Contributor

fzurita commented May 3, 2016

Yeah, I have had it disabled for this testing.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

May be uBlendMux2 uniform is used being uninitialized. Please try to replace ShaderCombiner::updateBlendMode by this code

void ShaderCombiner::updateBlendMode(bool _bForce)
{
    m_uniforms.uBlendMux1.set(gDP.otherMode.c1_m1a,
                              gDP.otherMode.c1_m1b,
                              gDP.otherMode.c1_m2a,
                              gDP.otherMode.c1_m2b,
                              _bForce);
    m_uniforms.uBlendMux2.set(gDP.otherMode.c2_m1a,
                            gDP.otherMode.c2_m1b,
                            gDP.otherMode.c2_m2a,
                            gDP.otherMode.c2_m2b,
                            _bForce);
    int forceBlend1 = gDP.otherMode.cycleType == G_CYC_2CYCLE ? 1 : 0;
    int forceBlend2 = 0;

    if (gDP.otherMode.forceBlender != 0 && gDP.otherMode.cycleType < G_CYC_COPY) {
        forceBlend1 = 1;
        if (gDP.otherMode.cycleType == G_CYC_2CYCLE) {
            forceBlend2 = 1;
        }
    }

    m_uniforms.uForceBlendCycle1.set(forceBlend1, _bForce);
    m_uniforms.uForceBlendCycle2.set(forceBlend2, _bForce);
}

It will guarantee that uBlendMux2 is initialized.

Owner

gonetz commented May 3, 2016

May be uBlendMux2 uniform is used being uninitialized. Please try to replace ShaderCombiner::updateBlendMode by this code

void ShaderCombiner::updateBlendMode(bool _bForce)
{
    m_uniforms.uBlendMux1.set(gDP.otherMode.c1_m1a,
                              gDP.otherMode.c1_m1b,
                              gDP.otherMode.c1_m2a,
                              gDP.otherMode.c1_m2b,
                              _bForce);
    m_uniforms.uBlendMux2.set(gDP.otherMode.c2_m1a,
                            gDP.otherMode.c2_m1b,
                            gDP.otherMode.c2_m2a,
                            gDP.otherMode.c2_m2b,
                            _bForce);
    int forceBlend1 = gDP.otherMode.cycleType == G_CYC_2CYCLE ? 1 : 0;
    int forceBlend2 = 0;

    if (gDP.otherMode.forceBlender != 0 && gDP.otherMode.cycleType < G_CYC_COPY) {
        forceBlend1 = 1;
        if (gDP.otherMode.cycleType == G_CYC_2CYCLE) {
            forceBlend2 = 1;
        }
    }

    m_uniforms.uForceBlendCycle1.set(forceBlend1, _bForce);
    m_uniforms.uForceBlendCycle2.set(forceBlend2, _bForce);
}

It will guarantee that uBlendMux2 is initialized.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

I did think that it may have been uninitialized, so I set it all zeroes always and that didn't work. But I'll try this as well.

Next thing I was going to try was to replace all array operations with non array operations.

Edit: Above didn't work either.

Edit2: Interesting, in the above method the forceBlend1 is never used with the original value before the original value is replaced.

Contributor

fzurita commented May 3, 2016

I did think that it may have been uninitialized, so I set it all zeroes always and that didn't work. But I'll try this as well.

Next thing I was going to try was to replace all array operations with non array operations.

Edit: Above didn't work either.

Edit2: Interesting, in the above method the forceBlend1 is never used with the original value before the original value is replaced.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

Ok, I finally had success..... I think there is something wrong with the driver.

In GLSLCombiner.h, I replaced:

        i4Uniform uBlendMux1, uBlendMux2;

with

        iUniform uBlendMuxC1_0, uBlendMuxC1_1, uBlendMuxC1_2, uBlendMuxC1_3;
        iUniform uBlendMuxC2_0, uBlendMuxC2_1, uBlendMuxC2_2, uBlendMuxC2_3;

And used everything that way.

There must be something wrong with the glUniform4i GL function in my driver.

Contributor

fzurita commented May 3, 2016

Ok, I finally had success..... I think there is something wrong with the driver.

In GLSLCombiner.h, I replaced:

        i4Uniform uBlendMux1, uBlendMux2;

with

        iUniform uBlendMuxC1_0, uBlendMuxC1_1, uBlendMuxC1_2, uBlendMuxC1_3;
        iUniform uBlendMuxC2_0, uBlendMuxC2_1, uBlendMuxC2_2, uBlendMuxC2_3;

And used everything that way.

There must be something wrong with the glUniform4i GL function in my driver.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

Good finding!
May be glUniform4iv will work better? It would be great, because glUniform4i can be easily replaced by
glUniform4iv. Use 8 uniforms instead of 2 uniform vectors is ugly.

Owner

gonetz commented May 3, 2016

Good finding!
May be glUniform4iv will work better? It would be great, because glUniform4i can be easily replaced by
glUniform4iv. Use 8 uniforms instead of 2 uniform vectors is ugly.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 3, 2016

Contributor

I had to head off to my job, so I'll give glUniform4iv a try tonight.

Contributor

fzurita commented May 3, 2016

I had to head off to my job, so I'll give glUniform4iv a try tonight.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 3, 2016

Owner

ok, good luck :)

Owner

gonetz commented May 3, 2016

ok, good luck :)

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 4, 2016

Contributor

Exact same issue with glUniform4iv. Now that I think about it, commenting out the glUniform4iv does not fix the issue.... so it can't be that. It must be a problem with the GLSL compiler. I don't think it likes this syntax:

 lowp vec4 blend1 = (muxPM[uBlendMux1[0]] * muxA[uBlendMux1[1]]) + (muxPM[uBlendMux1[2]] * muxB[uBlendMux1[3]]);    \n"

Even though it compiles it just fine, it must be doing something wrong with it.

Edit1: This doesn't work either:

static
const char* fragment_shader_blender1 =
"  if (uForceBlendCycle1 != 0) {                        \n"
"    lowp int uBlendMuxC1_0 = uBlendMux1[0];            \n"
"    lowp int uBlendMuxC1_1 = uBlendMux1[1];            \n"
"    lowp int uBlendMuxC1_2 = uBlendMux1[2];            \n"
"    lowp int uBlendMuxC1_3 = uBlendMux1[3];            \n"
"    muxPM[0] = clamp(vec4(color2, alpha2), 0.0, 1.0);  \n"
"    muxA[0] = muxPM[0].a;                              \n"
"    muxB[0] = 1.0 - muxA[uBlendMuxC1_1];               \n"
"    lowp vec4 blend1 = (muxPM[uBlendMuxC1_0] * muxA[uBlendMuxC1_1]) + (muxPM[uBlendMuxC1_2] * muxB[uBlendMuxC1_3]);    \n"
"    color2 = clamp(blend1.rgb, 0.0, 1.0);              \n"
"    alpha2 = muxA[0];                                  \n"
"  }                                                    \n"
;

static
const char* fragment_shader_blender2 =
"  if (uForceBlendCycle2 != 0) {                \n"
"    lowp int uBlendMuxC2_0 = uBlendMux2[0];    \n"
"    lowp int uBlendMuxC2_1 = uBlendMux2[1];    \n"
"    lowp int uBlendMuxC2_2 = uBlendMux2[2];    \n"
"    lowp int uBlendMuxC2_3 = uBlendMux2[3];    \n"
"    muxPM[0] = vec4(color2, alpha2);           \n"
"    muxA[0] = alpha2;                          \n"
"    muxB[0] = 1.0 - muxA[uBlendMuxC2_1];       \n"
"    lowp vec4 blend2 = muxPM[uBlendMuxC2_0] * muxA[uBlendMuxC2_1] + muxPM[uBlendMuxC2_2] * muxB[uBlendMuxC2_3];    \n"
"    color2 = clamp(blend2.rgb, 0.0, 1.0);      \n"
"  }                                            \n"
;

I guess the only thing left is that a vec4 uniform exists.... All I can think of.

Edit 2: Ok, bad news, my original fix to replace the vec4 uniforms with ints doesn't work, it only just delays the problem....

Edit 3: If I remove this piece of code, the problem also goes away:

    if (config.generalEmulation.enableNoise != 0) {
        _strShader.append(
            "  if (uColorDitherMode == 2) colorNoiseDither(snoise(), color2);   \n"
            "  if (uAlphaDitherMode == 2) alphaNoiseDither(snoise(), alpha2);   \n"
            );
    }

This leads me to believe that it's a similar problem to what @gonetz had the first time around that he managed to fix. But he only managed to fix it for nvidia.

Contributor

fzurita commented May 4, 2016

Exact same issue with glUniform4iv. Now that I think about it, commenting out the glUniform4iv does not fix the issue.... so it can't be that. It must be a problem with the GLSL compiler. I don't think it likes this syntax:

 lowp vec4 blend1 = (muxPM[uBlendMux1[0]] * muxA[uBlendMux1[1]]) + (muxPM[uBlendMux1[2]] * muxB[uBlendMux1[3]]);    \n"

Even though it compiles it just fine, it must be doing something wrong with it.

Edit1: This doesn't work either:

static
const char* fragment_shader_blender1 =
"  if (uForceBlendCycle1 != 0) {                        \n"
"    lowp int uBlendMuxC1_0 = uBlendMux1[0];            \n"
"    lowp int uBlendMuxC1_1 = uBlendMux1[1];            \n"
"    lowp int uBlendMuxC1_2 = uBlendMux1[2];            \n"
"    lowp int uBlendMuxC1_3 = uBlendMux1[3];            \n"
"    muxPM[0] = clamp(vec4(color2, alpha2), 0.0, 1.0);  \n"
"    muxA[0] = muxPM[0].a;                              \n"
"    muxB[0] = 1.0 - muxA[uBlendMuxC1_1];               \n"
"    lowp vec4 blend1 = (muxPM[uBlendMuxC1_0] * muxA[uBlendMuxC1_1]) + (muxPM[uBlendMuxC1_2] * muxB[uBlendMuxC1_3]);    \n"
"    color2 = clamp(blend1.rgb, 0.0, 1.0);              \n"
"    alpha2 = muxA[0];                                  \n"
"  }                                                    \n"
;

static
const char* fragment_shader_blender2 =
"  if (uForceBlendCycle2 != 0) {                \n"
"    lowp int uBlendMuxC2_0 = uBlendMux2[0];    \n"
"    lowp int uBlendMuxC2_1 = uBlendMux2[1];    \n"
"    lowp int uBlendMuxC2_2 = uBlendMux2[2];    \n"
"    lowp int uBlendMuxC2_3 = uBlendMux2[3];    \n"
"    muxPM[0] = vec4(color2, alpha2);           \n"
"    muxA[0] = alpha2;                          \n"
"    muxB[0] = 1.0 - muxA[uBlendMuxC2_1];       \n"
"    lowp vec4 blend2 = muxPM[uBlendMuxC2_0] * muxA[uBlendMuxC2_1] + muxPM[uBlendMuxC2_2] * muxB[uBlendMuxC2_3];    \n"
"    color2 = clamp(blend2.rgb, 0.0, 1.0);      \n"
"  }                                            \n"
;

I guess the only thing left is that a vec4 uniform exists.... All I can think of.

Edit 2: Ok, bad news, my original fix to replace the vec4 uniforms with ints doesn't work, it only just delays the problem....

Edit 3: If I remove this piece of code, the problem also goes away:

    if (config.generalEmulation.enableNoise != 0) {
        _strShader.append(
            "  if (uColorDitherMode == 2) colorNoiseDither(snoise(), color2);   \n"
            "  if (uAlphaDitherMode == 2) alphaNoiseDither(snoise(), alpha2);   \n"
            );
    }

This leads me to believe that it's a similar problem to what @gonetz had the first time around that he managed to fix. But he only managed to fix it for nvidia.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 4, 2016

Owner

Is it the only device, which has issues with new blending?

Owner

gonetz commented May 4, 2016

Is it the only device, which has issues with new blending?

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 4, 2016

Contributor

I should probably try my Nexus player which has a PowerVR GPU. My NVidia Shield TV had no issues.

Contributor

fzurita commented May 4, 2016

I should probably try my Nexus player which has a PowerVR GPU. My NVidia Shield TV had no issues.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 4, 2016

Owner

I tested with NVidia Shield Tablet and Note3 (adreno 330), no new issues.
As I understand, GLSE2 build works ok on your adreno device, so it will not be completely broken when this feature will come to master.

Owner

gonetz commented May 4, 2016

I tested with NVidia Shield Tablet and Note3 (adreno 330), no new issues.
As I understand, GLSE2 build works ok on your adreno device, so it will not be completely broken when this feature will come to master.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 4, 2016

Contributor

True, also, disabling noise emulation also works.

Contributor

fzurita commented May 4, 2016

True, also, disabling noise emulation also works.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 4, 2016

Contributor

Just tried on the Nexus player with a PowerVR GPU with GLES 3.1. It works fine albeit extremely slow like it had always been.

The weird thing is that the first time I ran it, the blending was all bugged, second time I ran it, it worked fine.

Contributor

fzurita commented May 4, 2016

Just tried on the Nexus player with a PowerVR GPU with GLES 3.1. It works fine albeit extremely slow like it had always been.

The weird thing is that the first time I ran it, the blending was all bugged, second time I ran it, it worked fine.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 5, 2016

Contributor

The reason I was asking was because in the PowerVR Android GPUs frame buffer emulation is very slow but only in GL ES 3.0 mode. The speed is fine in GL ES 2.0. I wonder if this is because GLES 3.0 is using FBOs.

Contributor

fzurita commented May 5, 2016

The reason I was asking was because in the PowerVR Android GPUs frame buffer emulation is very slow but only in GL ES 3.0 mode. The speed is fine in GL ES 2.0. I wonder if this is because GLES 3.0 is using FBOs.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 5, 2016

Owner

GLES2 uses FBO as well.
You may disable frame buffer emulation and compare speed. GLES3 shaders are more complex, it can be the reason.
Regarding FB emulation: the main difference is that GLES3 uses glBlitFramebuffer to draw FBO on screen, while GLES2 renders textured rect with glDrawArrays. glBlitFramebuffer should work faster. Again, you may try to use GLES2 method with GLES3: replace

#ifndef GLES2
void FrameBufferList::renderBuffer(u32 _address)

by

#if 0
void FrameBufferList::renderBuffer(u32 _address)

Owner

gonetz commented May 5, 2016

GLES2 uses FBO as well.
You may disable frame buffer emulation and compare speed. GLES3 shaders are more complex, it can be the reason.
Regarding FB emulation: the main difference is that GLES3 uses glBlitFramebuffer to draw FBO on screen, while GLES2 renders textured rect with glDrawArrays. glBlitFramebuffer should work faster. Again, you may try to use GLES2 method with GLES3: replace

#ifndef GLES2
void FrameBufferList::renderBuffer(u32 _address)

by

#if 0
void FrameBufferList::renderBuffer(u32 _address)

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 5, 2016

Owner

Another important difference between GLES2 and GLES3 is that GLES3 uses uniform blocks. Use of uniform blocks should improve performance, because it allows to change block of data for all shaders with just one GL call. GLES2 does not support that feature and thus it uses standard uniforms. May be GLES3 does not work well with uniform blocks.

Owner

gonetz commented May 5, 2016

Another important difference between GLES2 and GLES3 is that GLES3 uses uniform blocks. Use of uniform blocks should improve performance, because it allows to change block of data for all shaders with just one GL call. GLES2 does not support that feature and thus it uses standard uniforms. May be GLES3 does not work well with uniform blocks.

@fzurita

This comment has been minimized.

Show comment
Hide comment
@fzurita

fzurita May 5, 2016

Contributor

Yeah, sure, I'll try those things out. Thanks for the info! Also, I just realized that my previous reply was to the wrong issue. But you seem to know what I was talking about.

Contributor

fzurita commented May 5, 2016

Yeah, sure, I'll try those things out. Thanks for the info! Also, I just realized that my previous reply was to the wrong issue. But you seem to know what I was talking about.

@gonetz

This comment has been minimized.

Show comment
Hide comment
@gonetz

gonetz May 5, 2016

Owner

Merged to master

Owner

gonetz commented May 5, 2016

Merged to master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment