Another, for instancing, if i do culling as above,then i may first pass the instance data(position) to the pipeline, then the actual vertices by the 2nd pass. As the count ratio of them is merely 4:1,or at most 12:1, i tended to think the culling pass cost not so little compared to the whole “vertices” sent . or maybe still a gain to cpu culling? is that right or not? thanks

However, you should know that no actual vertex data is passed to the culling pass so that’s not true that vertex data has to be sent twice as you use only the instance data buffer in the culling pass.

In most cases, actually not the culling pass that takes time but the waiting for the culling results is the one that is rather expensive.

Actually there is a solution for both problems (i.e. for non-instanced data and query result delay) if you use OpenGL 4.2+ and I plan to write a demo that will show this technique, however, the technique presented in this article provides advantages only in case of instanced data and in case the instance count is relatively high.

And yeah it helps, makes sense now, it was geting me really frustrated, I am so used to thinking that everything needs to be sequential.

Actually querying transform feedback is a cheap operation, the only problem is that the query blocks by default until the results are available. So for you it seemed expensive only because you waited for the latecy between the geometry culling pass and the query results retrieval. In practice you should fill that time with other rendering tasks so you don’t have to stall the CPU (and inherently the GPU) by using blocking query readback.
In your case when you have several blocks to cull I would do it in the following way:

for i = 1 to block.count do
cull_with_geometry_shader(block[i])
endfor

for i = 1 to block.count do
inst_count = get_query_result(i)
draw_instanced(block[i], inst_count)
endfor

I hope this helps.

Btw I ran your demo with my GT9500, and while I can not remember the fps, it ran quite fluently)