I am having a problem after moving the code for the initialization of the display list from tghe main thread to a different thread.
I am programming with Winforms and .NET Framework 3.5
If I leave the initializatio of the display lists in the main thread everything works fine, but when I create a background worker and move the initialization inside the background worker, the glGenLists function returns zero.
Does anybody know I can I overcome this problem?
I’d like to use a separate thread to avoid the GUI freezing when loading the display lists.
As far as I’m aware, there’s not an easy away around this. You’ll want to keep your GL calls on the same thread. I’m guessing it’s not specifically your OpenGL calls in the list that are taking a long time, but other functions like loading models and textures and such. If this is the case, you should use the second thread just to get that information ready for a display list. Then on your GUI thread, use the data which has been stream-lined for making a list out of.
Actually I am already loading all the data from file to system memory in a different thread, but since it is a lot of data, even the simple iteration on the structures to initialize the display lists and transfer all the data from system memory to the graphic card memory is taking several seconds and I don’t want my GUI to freeze.
I can’t believe there is not a way to solve this problem, the process is the same, it’s just the thread which is different, and in any case I don’t understand why the glGenLists function returns zero, the initialization should work even on the separate thread. At most it should not be possible to call a display list which has been generated in another thread, but here is the generation which does not work at all if I move it in a separate thread. So what’s wrong?
You know, Display List are not perfect. They have even been deprecated from GL 3.x/4.x
They are only good for static stuff, as the compile time can be huge.
If you want more dynamic/async data upload/modern features etc, use VBO.
Actually I have only static stuff, so display lists are ok for me… So the question is: are VBO really faster? and the most important question: is it possible to create them in a thread and call them in another thread?
In my experience, no. If you optimize your triangle order and use NVidia bindless to dispatch them, then and only then does their performance nearly equal display lists (on an NVidia GPU).
Of course, the bigger your batches, the less the disparity between VBOs and display lists because batch dispatch overhead per triangle drawn is less.
However, if you don’t use bindless to dispatch, the performance is not as good as display lists, and can paradoxically be quite a bit worse than client arrays in many cases.
…and the most important question: is it possible to create them in a thread and call them in another thread?
Without performance impacts? I doubt it. Because display lists need to allocate VBO memory on the GPU for the batch data and upload that batch data, that background thread has got to own the GPU connection for a bit (assuming it can’t be shared) while it uploads the data. That’s probably going to hit perf on your foreground thread. Caveat: this is just my intuition.
But hey, try it and see. I’m no driver developer. Give that background thread its own GLXContext, make it current, go merily building big display lists, and see what happens! Conventional wisdom says context swap overhead will hit your perf.