DrawMeshInstancedIndirect broken with URP 10

[sebas771]

according renderdoc Graphics.DrawMeshInstancedIndirect is not defining the define PROCEDURAL_INSTANCING_ON with URP 10.x and this broke my rendering pipeline.

this at least on windows with DX11

[UnityMaru]

Have you submitted a bug report on this, if you’re suggesting it is one? Let me know with the ID so I can raise internally for you.

[sebas771]

No I didn’t, I don’t want to sound like a jerk this time but you should already have an automated test to prove if I am right or wrong.

[hatless]

Fix your product unity

[sebas771]

I had some spare time and I decided to work on the bug report, when I realised that nowhere in the documentation there is actually written what generates the shader define PROCEDURAL_INSTANCING_ON. One can only guess, so if I have no official information about it, I am not even sure what’s the point. this define is mentioned only once in the documentation but doesn’t explicitly say what enables it @UnityMaru

[UnityMaru]

@sebas771

I had some spare time and I decided to work on the bug report, when I realised that nowhere in the documentation there is actually written what generates the shader define PROCEDURAL_INSTANCING_ON. One can only guess, so if I have no official information about it, I am not even sure what’s the point. this define is mentioned only once in the documentation but doesn’t explicitly say what enables it @UnityMaru

Well, a bug report is not really just so we have a log of it. It sends us key information on your setup to help us diagnose the problem. I only asked as you used the thread prefix ‘bug’.

I certainly wouldn’t ask for a bug report to waste your time so I am sorry if you felt that way. More bug reports gives teams more information to look at issues so because we may have one report on the issue, more and more reports goes a long way to establish user pain and more data to analyse.

[sebas771]

thanks, but now we are beyond that point. I have now realised that my bug may be a wrong assumption, but without knowing what actually defines PROCEDURAL_INSTANCING_ON I can’t know.

[UnityMaru]

@sebas771

thanks, but now we are beyond that point. I have now realised that my bug may be a wrong assumption, but without knowing what actually defines PROCEDURAL_INSTANCING_ON I can’t know.

Understandable. I’ll ask around internally for you and see what I can get

[ptbs]

One possible cause for this I just encountered when porting some code from
Graphics.DrawMeshInstanced to
Graphics.DrawMeshInstancedIndirect is that you’ve missed out the pragma used by Unity to define the procedural instancing variant, a simple example is to do:

#pragma instancing_options procedural:setup

void setup()
{}

For more details see Unity - Manual: GPU instancing

Specifically:

procedural:FunctionName Use this to instruct Unity to generate an additional variant for use with Graphics.DrawMeshInstancedIndirect.
At the beginning of the vertex Shader stage, Unity calls the function specified after the colon. To set up the instance data manually, add per-instance data to this function in the same way you would normally add per-instance data to a Shader. Unity also calls this function at the beginning of a fragment Shader if any of the fetched instance properties are included in the fragment Shader.

[sebas771]

interesting, I don’t know what that pragma is for. We use GPUInstancer that adds:

#pragma instancing_options procedural:setupGPUI

shall I add the

#pragma instancing_options procedural:setup

too?

(reading the documentation it doesn’t seem to be the case, maybe it’s a bug in GPUI then?)

BTW I don’t have this problem anymore, we are using HDRP now and I don’t even remember what problem was this causing.