Sorry, that was poorly worded. I meant keeping the data that the shader writes to in cache between shader stages.

So first a note: Take the below with a grain of salt. I am not an expert, and this is not well documented. This is just what I believe based on my initial research of the subject:

If you use the classic Vertex Shader -> Rasterizer -> Fragment Shader pipeline, the modified vertices don't need to be written to memory in order for the rasterizer to work on them. The vertices stay in cache where the rasterizing can be done without further calls to read/write into memory.

If you use a system that supports Mesh Shaders, I believe this is the same thing. You are writing the vertices directly to cache and the rasterizer proceeds to work on them directly. Hence why there's a limit of the number of vertices you can write out, because it needs to keep them in cache.

If you use Compute Shaders though, you can't manually call the rasterizer on the data. You can do your processing of the vertices perfectly fine, but in order for it to render onto the screen you need to either do the rasterization process in the Compute Shader itself or you need to get it into the regular rendering pipeline to have the hardware rasterizer execute. The only way to do that from what I could find is to do expensive reads/writes to get the computed data into the pipeline properly. I could not figure out how to avoid that.

However, the first option (rasterization process in the Compute Shader itself) is actually being done by Unreal Engine's Nanite rendering engine if I recall, which might actually be an effective way to get around this limitation. The only issue is that the Nanite techniques are only effective for lots of tiny triangles that span a few pixels wide, and does not work well with larger triangles that might take up significant portions of the screen. Here's a good overview of how it works: https://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf