opengl - Display list vs. VAO performance -
i implemented functionality in rendering engine make able compile models either display lists or vaos based on runtime setting, can compare 2 each other.
i'd prefer use vaos, since can make multiple vaos sharing actual vertex data buffers (and since aren't deprecated), find them perform worse display lists on nvidia (gtx 560) hardware. (i want keep supporting display lists anyway support older hardware/drivers, however, there's no real loss in keeping code handling them.)
the difference not huge, measurable. example, @ point in engine state can consistently measure drawing loop using vaos take, on rather consistent average, 10.0 ms complete cycle, can switch display lists , observe cycle time decrease 9.1 ms on consistent average. consistent, here, means cycle deviates less ±0.2 ms, far less difference.
the thing changes between these settings drawing code of normal mesh. changes vao code opengl calls thusly...
glbindvertexarray(id); gldrawelements(gl_triangles, num, gl_unsigned_short, null); // using index array in vao
... display-list code looks follows:
glcalllist(id);
both code paths apply other states various models, of course, happens in exact same manner, should differences. i've made explicitly sure not unbind vao unnecessarily between draw calls, that, too, turned out perform measurably worse.
is behavior expected? had expected vaos perform better or @ least equally display lists, since more modern , not deprecated. on other hand, i've been reading on webs nvidia's implementation has particularly optimized display lists , all, i'm thinking perhaps vao implementation might still lagging behind. has else got findings match (or contradict) mine?
otherwise, doing wrong? there known circumstances make vaos perform worse should, on nvidia hardware or in general?
for reference, i've tried same differences on intel hd graphics (ironlake) well, , there turned out using vaos performed rendering directly memory, while display lists worse either. wish had amd hardware try on, don't.
Comments
Post a Comment