Simple/efficient way to draw static, passive, procedurally generated meshes?

I am converting my tiled, infinite procedural terrain code to DOTS. Mesh generation is done on CPU and is now using Burst to create the meshes in 2019.3.

My old version of the code was using a GameObject for each mesh which is definitely not the right way to do it.

I am confused about how to handle the drawing of the meshes in a simple and efficient manner and if I should use entities or not. Most entity examples seem to assume a workflow using prefabs and gameobjects and a need for iterating through entities each frame.

My assumptions:
- Mesh data is generated procedurally (no prefabs or gameobjects)
- All meshes are unique, but share the same material
- All meshes are not moving and not changing in any way
- No need to iterate through meshes on Update (except for drawing them)
- Target is VR so GC allocations should be kept at a minimum to avoid spikes (might need to pool Mesh objects)
- Mesh count is typically between a few hundred to a few thousand

As far as I can tell I have several options: 1) use some sort of ECS (possibly hybrid ECS), 2) draw the meshes manually with DrawMesh or 3) use computebuffers and DrawProceduralIndirect(). Maybe there's more?

I'm unsure which will be most efficient and I'm unsure what a simple ECS implementation would look like since most examples use prefabs/gameobjects and assume iteration on each update.

Edit: clarification about iteration. I don't need to run any code on the tiles on update, but of course I do need to draw them.

 

I tried using

DrawMesh

and the

HybridRenderer

, but eventually just settled on this: use Job+Burst on the vertices, tris, uvs manipulation, then just put the results in a mesh on the MeshRenderer on a GameObject.

Some considerations:
https://forum.unity.com/threads/project-available-hybrid-renderer-sandbox.681142/
https://forum.unity.com/threads/rendermeshsystemv2-has-substantial-amount-of-memory-leak.672679/