I'm by no means a big voice in the industry, but I second Manuel and everyone else's stance in this ticket and on the rare related posts in the forums. I'd also like to add a few facts on the matter:
- Both MultiDraw and MultiDrawIndirect(/Count) exist in Vulkan despite doing away with some OpenGL features that weren't deemed useful (like the shader subrountines).
- The Vulkan docs still mention that these can reduce overhead.
- D3D12 has support for MDI in the form of ExecuteIndirect (D3D11 has vendor-specific extensions for it).
- OpenGL/ES have supported MultiDraw since the fixed function days and the indirect version since 12-13 years.
- The somewhat recent interview of an Intel Arc engineer on GamersNexus showed that they realized MultiDrawIndirect is actually useful and can give a significant improvement in performance (when hardware-supported (?), which is the case for all dGPU vendors since Battlemage. Probably check against Vulkan 1.2 for mobile). That's knowing that Arc GPUs were always meant to be designed around low-level APIs.

Adding support for MDI doesn't cost much to Unity at this point, and a fallback to separate indirect calls in the render pipelines (not the rendering API) when the hardware doesn't support the feature should be trivial. The fact that Unity still doesn't support this is completely insane. A proper GPU-driven workflow should visibly increase the scalability of scenes and should decrease user responsibility for batching their assets, which can allow them to focus more on the artistic vision rather than doing the renderer's job.

I feel I could speak for days about this. If this actually won't provide a benefit, I feel it'd be necessary to have an unlocked, official, lengthy, technical forum thread about why. This SHOULD be a major point in the roadmap alongside the GPU driven rendering path. PLEASE.

PS: how many captchas do I need to go through while writing this???

The resolution note has now changed from "won't fix" to an actual answer, thank you for that. I'll just copy my answer from your bug reporting tool over here as well.

--------------------------------------------------------------------------------------------------------------

That is disappointing to hear. Even if brg highly optimizes its direct draw calls on the cpu side, you will never reach the performance potential of indirect gpu driven rendering with it. Since we do frustum culling on the gpu, we have to issue every single possible draw call for every mesh and lod in the scene, even though most of them will end up empty. So yes, we DO have a large number of draws that could be batched. MDI could not only batch these draw calls, but could even create them directly on the gpu and cull the empty ones if implemented fully.

I’m sure you’ve seen the votes and comments on the issue tracker and forum thread. My voice alone in this represents a medium sized studio that wants to switch to gpu driven rendering and already has developed the necessary systems, but the draw counts still stick out like a sore thumb. We were really banking on the functionality being fixed according to the docs, and not the docs being “corrected”.

With all that being said, since this is now a feature request, I would appreciate it if you could 1) add the full MDI implementation to it, which includes draw call generation on the gpu, and 2) add it to your public roadmap so your customers can vote on it.

Thank you.

So really that is what you have to say? "There are no fixes planned for this Bug", are you fuck****ing kidding us ?

It is ridiculous that you are once again closing this with no comment, no explanation, no plans whatsoever, especially after so many of your customers have voted on it and voiced their need for MDI working correctly. Why even open the report back up after the first time? You actually cannot be serious.

Really hoping this gets fixed soon...

We really need MDI to draw large scenes. This feature not being properly implemented is negatively impacting us and our customers. Supporting a custom render api is expensive and difficult to maintain. Hope this is implemented soon.

Come on guys.. we need a solution for this, please!

I am also in need of this feature as it could allow me to optimize my instance indirect foliage system. Currently by having to "emulate" all the commands instead of dispatching real commands. This not only causes all my vertex and index buffers to be redundantly rebound, but also breaks the GPU's ability to parallelize rendering vertex shaders of multiple command arg elements. A shame that this is implemented for the hybrid entities renderer (or what it looks like when viewing Radeon AMD profiler) and it isn't exposed to the user. Pls fix

In my case on an Android device this causes the frame rate to drop from 60 fps to 20 and it took me a few days to figure out what it was.

Any update on this?? our team is literally counting on this, also why SV_DrawID semantic s not provided ? it is easy to simulate and fix, i mean common unity this has been used by many games for a decade.