c# - Possible Rendering Performance Optimizations -

i doing benchmarking today using c# , opentk, see how render before framerate dropped. numbers got pretty astronomical, , quite happy outcome of tests.

in project loading blender monkey, 968 triangles. instance , render 100 times. means rendering 96,800 triangles per frame. number far exceeds need render during given scene in game. , after pushed further , rendered 2000 monkeys @ varying locations. rendering whopping 1,936,000 (almost 2 million triangles per frame) , framerate still locked @ 60 frames per second! number blew mind. pushed further , framerate started drop, means limit 4 million triangles per frame instancing.

i wondering though, because using legacy opengl, if still pushed further—or should bother?

for tests load blender monkey model, store display list using deprecated calls like:

modelmeshid = meshgenerator.generate( delegate {             gl.begin( primitivetype.triangles );             foreach( face f in model.faces ) {                 foreach( modelvertex p in f.points ) {                     vector3 v = model.vertices[ p.vertex ];                     vector3 n = model.normals[ p.normal ];                     vector2 tc = model.texcoords[ p.texcoord ];                     gl.normal3( n.x , n.y , n.z );                     gl.texcoord2( tc.y , tc.x );                     gl.vertex3( v.x , v.y , v.z );                 }             }             gl.end();         } ); 

and call list x amount of times. my question though, if speed if threw vao's (vertex array objects) display list instead of old gl.vertex3 api? effect performance @ all? or create same outcome display list?

here screen grab of few thousand:

my system specs:

cpu: amd athlon iix4(quad core) 620 2.60 ghz graphics card: amd radeon hd 6800 

my question though, if speed if threw vao's (vertex array objects) display list instead of old gl.vertex3 api? effect performance @ all? or create same outcome display list?

no.

the main problem you're going run is, display lists , vertex arrays don't go each other. using buffer objects kind of work, display lists themself legacy immediate mode drawing api.

however, if manage vbo drawing within display list right, there'll improvement: when compiling display list opengl driver knows, arriving "frozen" eventually. allows aggressive internal optimization; geometry data packed buffer object on gpu, state changes coalesced. amd not quite @ game nvidia, they're not bad either; display lists heavily used in cad applications , before ati addressed entertainment market, focused on cad, display list implementation not bad @ all. if pack relevant state changes required particular drawing call display list, when calling display list you'll drop fast path.

i pushed further , framerate started drop, means limit 4 million triangles per frame instancing.

what's limiting there overhead on calling display list. suggest add little bit more geometry dl , try again.

display lists shockingly efficient. got removed modern opengl because can used immediate mode drawing commands. recent things transform feedback , conditional rendering have been difficult integrate display lists. got removed; , rightfully so, because display lists kind of awkward work with.

now if @ vulkan essential idea set of drawing commands (state changes, resource bindings , on) upfront in command buffers , reuse varying data. if create multiple display lists , have them make babies.