Currently, I’m dealing with a rendering engine that uses OpenGL 1.2 for drawing certain graphs. The current design is such that each render, the canvas is cleared and each object that needs to be drawn is issued a separate draw call and are rendered with OpenGL 1.2 API. Separate draw calls are issued because the visibility may be controlled by an external logic.
For a 50000 similar objects performance test, the draw happens seamlessly.
For business reasons, we wanted to move the rendering engine to OpenGL 2.0 + . So I got simple vertex and fragment shaders in, re-wrote certain device rendering classes to land with the above design but calls via the OpenGL shader path. What this implies is that for each object draw we basically write to a single one-object VBO (created and bound once at initialization with GL_DYNAMIC_DRAW) to draw each of the objects for which the calls are being received. Let’s call this Option 1 - the Least change path.
Now we test on 3 cards - Intel, NVIDIA and Matrox.
On NVIDIA this works fairly well - the application loads in 3-4 seconds. On Intel (24.x driver) it worked fine but with newer drivers (27.x and 30.x) the application has become unusable (rendering takes too long at initialization ), upto a minute, and on Matrox it’s sluggish (10-12 seconds to initialize).
Now for technical argument’s sake I re-wrote (dirty hacks) all the calls to go to one big VBO containing all the 50k objects and everything works fine => Application loads in 3-4 seconds. Let’s call this Option 2- the ideal path.
Option 1 is what I want to stick with for it’s simplicity and maintainability AND also Option 2 is expensive maybe infeasible too.
So here’s a list of questions if individually answered will be really helpful for me to conclude this exercise -
Q1) WHY the application becomes sluggish/unusable when a single one-object VBO is written to multiple times to draw many objects? My assumption is that the overhead should be of data transfer to the GPU but which again should be fairly fast. But is there something else about the pipeline or the driver that I’m breaking?
Q2) If technically there’s nothing wrong with Option 1, then what are the aspects I can check are being done right to ensure there is a performance rise. While I understand and appreciate that each vendor may optimize differently, can I get the driver to be performant to this scenario?
Q3) If technically Option 1 is incorrect, then is it implicit that programmable pipelines mean creating larger VBOs by transferring data to the VBO once and only modifying when something changes? Basically lesser transfers and more draw calls?
Q4) If answer to Q3 is that yes larger VBOs are required, then does sticking to older OpenGL versions stand as a valuable alternative obviously until one of the vendors stop support for older GL versions.