Emulator

While playing through Metroid Prime 1 on Android recently, I noticed that the map performance with Vulkan was quite good compared to OpenGL (consistently 30FPS+ with Vulkan, 8-10FPS at best with OpenGL). With OpenGL, the map is especially slow in the Chozo Ruins and Phendrana Drifts regions, but renders at a usable speed in other regions.

That could probably be because your device doesn't support geometry shaders in Vulkan. Without geometry shaders, it runs a lot faster but the lines are too thin.

I somewhat understand why the game does this. For most of the lines, it's changing one of the constant (or "konstant") colors the TEV has access to, but nothing else. The function that normally does this, GX_SetTevKColor, writes red + alpha, then blue + green, then blue + green again, then blue + green a third time. Libogc says "this two calls should obviously flush the Write Gather Pipe", but what seems important to me is that each write is 5 bytes of data each (0x61 to indicate it's a BP command, the command number (0xe1), and then 3 bytes of data), so the extra 2 blue + green writes are 10 bytes. (The write gather pipe stores groups of 32 bytes, so I don't think this is actually a flush, but it's doing something to work around a hardware quirk.) Metroid Prime's triangles end up being 11 bytes: 0x98 to start a triangle strip, and then 00 08 for the length (8 vertices), and then 00 00 00 00 00 00 00 00 for the actual vertices (which is just the same position 8 times.) So this is probably just a way of working around the same issue.

However, they also send though similar triangles after changing only the line-width configuration, which normally doesn't have a similar flush. I don't know why that might be.

As far as I can tell, the value 0 here doesn't have any special meaning: it really is just referring to index 0, which may be on screen, so culling off-screen triangles (like in PR 11208 won't necessarily help. We could skip degenerate triangles, but I don't know how much of a gain that would be, as changing the point size or line size still would break batching to my understanding.

Actually, I can verify this by skipping triangle strips entirely (by adding if (primitive == OpcodeDecoder::Primitive::GX_DRAW_TRIANGLE_STRIP) return size to VertexLoaderManager::RunVertices); this obviously breaks things, but would be faster than the best case that could be achieved by skipping unwanted triangle strips (since it just skips them all). And that does seem to be the case in practice: performance does increase a fair bit, but there are still 4451 draw calls. I'm not entirely sure how to count D3D calls, but in renderdoc with D3D11, there are 67K EIDs with this change, and 167K without, and in Vulkan, there are 20K EIDs with this change, and 56K without. (I'm not really sure what to make of these numbers, since of course it is skipping a lot of actually important rendering.)

It does seem to be the case that a lot of stuff that's getting drawn (both lines and triangles) is off screen, though, so culling may still help in that way.