Wireframes in SiN Episodes Emergence

[niobium93]

Smoke and flames in this game appear as a mess of wireframes. Everything appears as wireframe through the pause menu and the hud. System info: Kernel 5.5.10, Wine Staging 5.4, wine-nine 0.5 and latest git, mesa 19.3.4 and 20.0.0, AMD Radeon RX 5700 XT gpu. Apitrace Terminal output

[axeldavy]

Thanks for this detailed bug report and the trace. The trace replays fine under wine and shows the glitch under nine so it should be easy to fix.

[axeldavy]

Hum, I'm quite confused by this bug.

I found one draw call drawing the fire with the bad dark lines in it (call 981762) And the fire is drawn as two triangles, thus it doesn't make sense to have several dark lines in it. The texture as displayed in apitrace doesn't have the artifacts. The draw states seem completly fine and normal... And the shaders used for the call are:

nine:0xf7b1b700:nine_ff_get_vs VS ff key hash: 7a397c
VERT
PROPERTY NEXT_SHADER FRAG
DCL IN[0]
DCL IN[1]
DCL IN[2]
DCL IN[3]
DCL OUT[0], POSITION
DCL OUT[1], COLOR
DCL OUT[2], COLOR[1]
DCL OUT[3], TEXCOORD[0]
DCL OUT[4], TEXCOORD[1]
DCL CONST[0][0..3]
DCL TEMP[0..2]
IMM[0] FLT32 {    0.0000,     1.0000,     0.0000,     0.0000}
  0: MUL TEMP[0], IN[0].xxxx, CONST[0][0]
  1: MAD TEMP[0], IN[0].yyyy, CONST[0][1], TEMP[0]
  2: MAD TEMP[0], IN[0].zzzz, CONST[0][2], TEMP[0]
  3: MAD OUT[0], IN[0].wwww, CONST[0][3], TEMP[0]
  4: MOV TEMP[1], IN[2]
  5: MOV OUT[3], TEMP[1]
  6: MOV TEMP[1], IN[3]
  7: MOV OUT[4], TEMP[1]
  8: MOV_SAT OUT[1], IN[1]
  9: MOV_SAT OUT[2], IMM[0].xxxx
 10: END
shader type: VS, preferred IR: NIR, selected IR: NIR
nine:0xf7b1b700:vertexshader9:ctor: This=0xcd0d5d60 pParams=0x32f818 pFunction=(nil) cso=0xcd0d3510

nine:0xf7b1b700:nine_ff_get_ps PS ff key hash: 2412000
nine:0xf7b1b700:nine_ff_build_ps STAGE[0]: colorop=MODULATE alphaop=MODULATE
nine:0xf7b1b700:nine_ff_build_ps STAGE[1]: colorop=MODULATE alphaop=MODULATE
FRAG
DCL IN[0], COLOR, COLOR
DCL IN[1], TEXCOORD[0], PERSPECTIVE
DCL OUT[0], COLOR
DCL SAMP[0]
DCL CONST[0][20]
DCL TEMP[0..4]
IMM[0] FLT32 {    0.0000,     0.0000,     0.0000,     0.0000}
  0: MOV TEMP[0], IN[0]
  1: MOV TEMP[1], IMM[0].xxxx
  2: MOV TEMP[2], IMM[0].xxxx
  3: TEX TEMP[2], IN[1], SAMP[0], 2D
  4: MUL TEMP[0], TEMP[2], IN[0]
  5: MUL TEMP[0], CONST[0][20], TEMP[0]
  6: MOV OUT[0], TEMP[0]
  7: END

Hard to make simpler, and definitely not the complexity to insert some dark lines. Inspecting the depth buffer I do not see the pattern neither before or after the call. This would point to the texture being corrupted when on the GPU, but not on the CPU (where apitrace reads, as the texture is MANAGED - ie CPU backing). That seems quite unlikely. All this is extremely weird. I'll need to do some tests with texture format replacement and forced reuploads, assuming the problem is really with the texture.

[axeldavy]

I'm ending my investigation today.

So far, it all behaves as it the fire texture has the artifacts when apitrace fills the content, and that magically the artifacts disappear of the cpu buffer after some time. Reuploading the fire content just before the draw call makes the artifact disappear for that texture, but reuploading a copy (though of a different format, as I used some format replacement path for that test) of the content filled by the app keeps the artifact. Yet the texture content is only filled once.

Hopefully it will make sense next time I investigate.

EDIT: upon further investigation it seems the bad pattern is already there before the fire is drawn but is extremely subtle. I guess the changes tested affected something else that is the culprit..

[Venemo]

I've run this apitrace too and found the following:

• The problem is present with radeonsi on latest mesa master.
• The problem is not present when running the same trace on iris.

Best guess is that the problem exists somewhere in radeonsi, but we're currently not sure what the problem is.

[dungeon007]

I cant reproduce this on GCN 1.1 APU, if not fixed recently then random guess could be a LLVM, maybe DCC issue....

[dungeon007]

"Best guess is that the problem exists somewhere in radeonsi, but we're currently not sure what the problem is." Maybe something like this: "That kind of artifacts is usually due to whole quad mode not being enabled when it should be." https://bugs.freedesktop.org/show_bug.cgi?id=88642