Which would be faster

depends on the GL_MAX_ELEMENT_VERTICES and GL_MAX_ELEMENT_INDICES.

I found that 64x64 patches are the fastest on my 7900GT.

DP

I called glGetIntegerv(GL_MAX_ELEMENTS_INDICES) and glGetIntegerv(GL_MAX_ELEMENTS_VERTICES) and both return 4096 on my 7800 GTX. Is this normal??

yes, thats the limit on the NV cards...

sqrt(4096) == 64x64

Im thinking thats the size of the FIFO buffers, anything above that will be stored in either vram, or ram causing the slowdowns causing unnecessary fetches, which only stall the pipeline anyway.

Regards,
DarkProphet :)

Well I plan on having all the vertices stored in video ram using VBOs. So there won't be any transfer across the bus. So does the MAX_ELEMENTS_VERTICES only apply when streaming the vertices from system memory to video memory? I was under the impression it had to do with how many vertices it can batch together efficiently when going through the vertex processor.

Rendering 4 128x128 patches of terrain using 16bit indices with 4 different calls to bind the vertex buffers and textures
would be faster though even better would be smaller patches of say size 33x33vertices

And why?

If you make small patches (33x33) you can occul (if thats the right word) patches that are out of view very easy.

Thats for sure, but usually if you have a fixed sized terrain you should create your patches to exactly fit into the index buffers.

And you should take care about the optimal VBO buffer size, which (I may be wrong here) is around 8.3 mb

If making things smaller == better performance, then might as well have a 2x2 terrain :P

Theres a relationship between the ratio of load on the CPU and on the GPU. You can spend alot of time culling away specific vertices so that its *exact*, but the load on the CPU would be too great, so, just sending those vertices down to the GPU will be much much faster. Frustum culling helps up to a point, then it becomes detrimental for performance.

As for the VBO question, the GL_MAX_ELEMENT_VERTICES will still apply as your transfering the data (in the VBO) from vram/systemram to the caches on the actual chip, and the size of the cache (hence the FIFO buffer comment) can only fit so much. Anything above that would hault rasterisation as another memory fetch is required to fill the cache again.

With the anything less then 4096 (on the NV gpus ofcourse, ATI and others vary), your having to go through the process 4 times to achieve the same results. I.e. fill the cache with 32x32, rasterise...etc; fill the cache up again and rasterise another 3 times to get the same number of triangles on the screen.

Regards,
DarkProphet :)