TomF, 11 months ago

@lisyarus Probably the draw count rather than the poly count? What you really need to do is draw more trees with fewer draw calls.

lisyarus, 11 months ago

@TomF It's poly count. Trees are 2 draw calls right now, one per each type :)

fell, 11 months ago

@lisyarus @TomF Are you using alpha blending? If yes, then the problem might be overdraw.

lisyarus, 11 months ago

@fell @TomF No, just alpha testing.

fell, 11 months ago

@lisyarus @TomF Then, all that's left is the vertex or fragment shader. If you're saying it's polycount, maybe simplifying the vertex shader is an option? Or frustum culling?

lisyarus, 11 months ago

@fell @TomF The vertex shader is as simple as it gets. Frustum calling won't help in worst cases which are unfortunately fairly typical in my case.

I've already tested a low-LOD model instead and it improves things significantly, I only need to implement proper distance-based LOD selection.

fell, 11 months ago

@lisyarus @TomF Interesting... I never thought modern hardware could be vertex limited. Especially not when the vertex shader is very simple.

Maybe it's because many triangles are overlapping in one spot, and that somehow prevents some GPU optimisation magic?

You are using depth testing, that should avoid unnecessary fragment shader invocations. So the rasteriser is the bottle neck? 🤔

TomF, 11 months ago

@fell @lisyarus Usually not the shading as such - it's the assembly of the shaded vertex data into triangles and setting up the interpolants. That's all data movement inside the chip, there's lots of caches that you don't control, and because those are all full-fat float32s with no compression possible, it's a big chunk of data, and that can easily be a bottleneck.