I have a fairly complex multithreaded film scanning application developed with Visual Studio C++ for Windows. The current OpenGL implementation is as follows:
- Performs all OpenGL Initialization, texture and shader creation in application thread.
- Initializes Main Viewing Window with rendering context in application thread.
- During scan execution, creates a separate worker thread and continuously uploads images, renders to FBO, and downloads finished images with no parallel GPU activity.
- Uses the application GL thread to view finished images on the application viewing window.
- Uses a separete worker thread to write finished image buffers to disk.
I have studied the NVidia Copy Engine white paper, as well as Ch. 28 and 29 of the OpenGL Insights text book, but am still somewhat confused as to the proper OpenGL thread construction to take advantage of the Quadro dual copy engines. The OpenGL Insights sample code is difficult for me to parse, as it uses a c++ class that encapsulates many of the OpenGL calls.
My initial questions are:
In the NVidia examples, the application thread is used for GL rendering, and shares its rendering context (wglShareLlists) with the upload thread. If my upload, render and download threads are all separate worker threads, does this change the context sharing structure?
Why does the render thread only need to share contexts with the upload thread, and not the download thread (finished frame)?
Regarding the Pixel Buffer Object buffers, I don’t quite understand the purpose of using two sets of buffers for both uploading and downloading. Is the reason to use one for even frames and one for odd frames, or is it use one to load from host memory and the other to copy the data from the from the first PBO to the second during one frame transfer?
If there is any dual copy-engine code out there that uses native OpenGL calls exclusively, I’d appreciate a link to it.