Bug 2019.3.0f5 Fail to render with SRP Batcher on Mali GPUs on big scenes

If you get around to it, a bug report would be much appreciated.

 

I've checked and there's no known issue in the database.

 

We are still missing a report + reproducible for this.

 

Thanks a lot! I've forwarded it to the team.

 

Hi!
Regarding glitches/crashes when rendering a lot of objects with SRP batcher (case 1214237): Mali GPU drivers have a fixed amount of temporary memory for varyings. On Vulkan the driver crashes when this limit is hit. OpenGL ES driver handles this internally, but this results in much lower poerformance.
We have some code to detect this on the engine side. If you see "Vulkan: Too much vertex data per render pass detected, this may cause rendering errors and instability. (only logged once)" in the console, this means we think you'll hit this limit.

Normally, if the application is generating that much varying data per frame, it's not going to be performant enough on these devices anyway. The only proper workaround for this is to reduce the amount of geometry rendered.

 

Let me take a look at the shader once more

 

Keep in mind that the issues you're experiencing might not be the same as the ones caused by the shader in @Silentor666's repro project that are tracked in 1214237. We would need to have a look at your project/reproducible to determine that.

 

Good to know

 

@Jes28 here's an example:
there's a mango tree in the project, the mesh has 10224 verts
looking into the shader, we have a PackedVaryings struct (stipping #ifdef'ed parts):

Code (CSharp):

1. struct PackedVaryings
2. {
3.     float4 positionCS : SV_Position;
4.     float3 interp00 : TEXCOORD0;
5.     float3 interp01 : TEXCOORD1;
6.     float4 interp02 : TEXCOORD2;
7.     float4 interp03 : TEXCOORD3;
8.     float3 interp04 : TEXCOORD4;
9.     float3 interp05 : TEXCOORD5;
10.     float2 interp06 : TEXCOORD6;
11.     float3 interp07 : TEXCOORD7;
12.     float4 interp08 : TEXCOORD8;
13.     float4 interp09 : TEXCOORD9;
14. };

The data generated by the vertex shader is 5x float4 + 5x float3 + 1x float2 = 2 + 15 + 20 floats = 37x4 bytes = 148 bytes per vertex.
If we render a single mango tree, we get 148 bytes x 10224 verts = 1 513 152 bytes of data = ~1.44MB.

The scene in question seems to be much more complicated than that. Suppose those 800K polygons are coming from just 800K vertices and are all rendered with this shader. We get 148 bytes x 800K = ~112 MB of data per frame for varyings. This data has to fit in the fixed buffer I mentioned So, if you use a simpler shader, it's likely to fit.

Let's take a look at this from another point: memory bandwidth. S8 with a Mali GPU has peak memory bandwidth of ~15 GB/s.
Let's assume the input data per vertex is pos (float3) + normal (float3) + tangent (float4) + color (byte4) + UV0 (float2) = 52 bytes. So each frame, just to read vertex attributes and to produce varyings, we need 52 (read) + 148 (write) = 200 bytes per vertex. 800K vertices means 160 000 000 byte, or ~152.5 MB per frame. Then there's a step needs to actually do the interpolation for the fragment shader (might be the fragment shader itself...), which needs to read the data generated by the vertex shader. Let's say a quarter of the triangles survive all the tests. We would then need half of the varyings data as input to the fragment shader = 56MB (read) per frame. Total memory transfers till this point score 208.5 MB.
If we want to run at 60 FPS, we use about 12.5 GB/s of memory traffic just for the geometry. No shadows, no textures, no writing to the framebuffer, no postprocessing

If you cut the amount of data used for varyings, you're going to have much less memory traffic. So using a simpler shader / using half where possible would help a lot

This is quite interesting info. A quick guess would be that the SRP batcher path uses more memory somewhere, which leads to hitting this limit.
Do you see the warning I mentioned above without the SRP batcher enabled?

 

It can be
I'll ask people doing shader graph.
Do you know if they allow to customize varying precision?

 

OK, it should now be in their backlog