Wierd particle state after reset the process material in GPUParticle2D

[jsjtxietian]

Tested versions

Godot v4.3.dev (89cc635c0)

System information

Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 31.0.15.4601) - 12th Gen Intel(R) Core(TM) i7-12700F (20 Threads)

Issue description

When trying to debug https://github.com/godotengine/godot/issues/87123, I sometimes notice that after reset the process material, the particle will go crazy like below:

give it the shader for the first time might looks like this:

I admit the shader here is not that valid, but it does look like that some state is not inited well. And even the shader is not good, reset it is supposed to give the correct ( normal ) result.

shader_type particles;

void start() {
    // Called when a particle is spawned.
    USERDATA1 = vec4(1.0f,1.0,1.0f,1.0);
}

void process() {
    // Called every frame on existing particles (according to the Fixed FPS property).
    //TRANSFORM[3] = USERDATA1;
}

See the video below, sometimes I can get the wierd result at the first try:

https://github.com/godotengine/godot/assets/8315986/1c501e0a-329d-4fb3-88c8-bc6ca434c210

Steps to reproduce

1. Make a GPUParticle2D
2. Give it a texture
3. Give it a Shader material and the related shader
4. reset and re-assign serveral times, observe

Minimal reproduction project (MRP)

GPUParticle2D.zip

[robbertzzz]

I'm seeing the same thing after testing #87123 as well. It looks like (un)commenting the USERDATA1 variable will constantly trigger a different glitch. It also happens with the other USERDATA variables for me.

Closing and reopening the project seems to fix the issue, so I don't think the repro project in the OP will be of much use (also similar to #87123). My guess would be that memory isn't being allocated for USERDATA variables until the initial shader compilation if it does contain that variable, and USERDATA overwrites other particle variables in memory in all other cases.

[edit]

Changing the amount parameter also seems to fix the issue

Also of note, each line you see in the screenshot in OP is a separate particle, as can be determined by the updated draw order. So it seems different portions of memory are being written to for each separate particle.