Large graphic appears when running (GLES3)

[Torguen]

Godot version:

3.3 rc9 mono

OS/device including version:

win10 64 radeon vega 8

Issue description:

The godot icon appears in a considerable size when executing. No node has scripts assigned. I can't minimize the error any more, this is the maximum I can minimize it. The error does not appear if you do one of these things: -If you delete the node "dureza" -If it makes the node "foca" invisible -If you delete the node "layerHUD" -If the graph of the node "layerHUD / backgroundHUD" changes. -If you delete the shader material assigned to the node "AlgasSuperiores" (the shader has no code) -If you change the node type "CapaProfundidad" (Node2D) to type "CanvasLayer" And more things that don't make sense and you can't come to a conclusion. I can't figure out the reason for the appearance of that graph at the start of the run. In the gif you can see what I mean, I have marked it with "this".

Steps to reproduce: Execute the project.

Minimal reproduction project:

juegoFoca.zip

[Calinou]

@Torguen Can you reproduce this after disabling batching in the Project Settings?

[Torguen]

@Torguen Can you reproduce this after disabling batching in the Project Settings?

I have disabled batching and the problem has been solved, so is it a bug?

It is also solved if I keep "Batching" activated and "Batching Stream" active.

[lawnjelly]

Do you know what your GPU is (and possibly drivers)? I can't seem to replicate it here (should I just run the project?).

If it gets cured by setting the batching stream flag, that's kind of strange, as I'm not sure the flag should affect the rendered result, only the mechanism used for uploading (that does possibly suggest a possible driver bug, but let's wait and see if others can reproduce).

[Torguen]

Do you know what your GPU is (and possibly drivers)? I can't seem to replicate it here (should I just run the project?).

If it gets cured by setting the batching stream flag, that's kind of strange, as I'm not sure the flag should affect the rendered result, only the mechanism used for uploading (that does possibly suggest a possible driver bug, but let's wait and see if others can reproduce).

It's a radeon vega 8 Updated to the latest version

Yes, I think it is necessary to execute the project.

[clayjohn]

I have run the reproduction project and can reproduce the error.

It flashes on the first frame only and then goes away.

I can confirm that batching_stream fixes the bug as well.

It appears to be linked to the fact that the user has a sprite with an empty shader assigned. Empty as in it doesn't even have a shader_type declared.

We probably need a check in batching to not batch items that have improper materials assigned.

Here is my batching frame printout, but im not sure it is applicable because the bug is only on the first frame.

canvas_begin FRAME 278
items
    joined_item 1 refs, 
        (z -2)
            batch R 0-1 [0 - 151] {255 255 255 255 }
    joined_item 1 refs, 
            batch R 0-1 [0 - 151] {255 255 255 255 }
    joined_item 1 refs, 
            batch R 0-39 [0 - 155] {255 255 255 255 } MULTI
    joined_item 1 refs, 
        (z 2)
            batch R 0-1 [0 - 151] {255 255 255 255 }
    joined_item 1 refs, 
        (z 2)
            batch R 0-1 [0 - 151] {255 255 255 255 }
canvas_end

canvas_begin FRAME 278
items
    joined_item 1 refs, 
            batch R 0-1 [0 - 154] {255 255 255 255 }
canvas_end

[lawnjelly]

I've tried video capturing just in case the frame was really quick but it doesn't seem to appear on mine on linux (intel GPU) (could it be something that appears on windows?). I have no idea why changing the upload flag affects things...

Agree the invalid material sounds fishy. This might need your help to debug @clayjohn if I can't reproduce. I did actually recently have do a PR fix where an invalid shader produced a different result with and without batching, I forgot the issue, I might try and dig it out tomorrow, I didn't get to the bottom of it, but decided that bad behaviour in an invalid shader was to be expected so it wasn't a massive problem.

Ah this was the PR: #46896 I'll have a look tomorrow and see if the misbehaviour could be related.

[lawnjelly]

I'm convinced this bug and the wrong behaviour with a broken shader in #46896 are related. I think it is simply missing a check for shader->valid, which gets set to false when the shader is broken.

Although I can't replicate the problem here, I can replicate what I think is a similar problem in #46873 by setting the shader code to something valid, then putting in a shader error (so it becomes invalid), which then shows the wrong result compared to the legacy renderer (white blocks).

I've managed to cure that bug (I think) by adding a check for shader->valid in the try_join logic, and preventing all joining when the shader is invalid. I'll prepare a PR for this, whether it will cure this large sprite issue I don't know - I'll need to get one of you guys to test it out. It is possible that there might be a need for another check for shader->valid somewhere else, but without being able to replicate it, makes it difficult on my end.

This bug has always existed it seems (since 3.2.2), but maybe it is only noticeable in certain circumstances. It only occurs in a kind of panic mode, where there is a user error in the shader, which should not happen in shipped games, so I'm not sure this has to be a blocker for 3.3 stable, but the fix so far should be not risky.

[akien-mga]

This might have been fixed in 3.3-stable (and should still be fixed in 3.4-rc1 or later), can you confirm?