Could anybody who’s aware of OpenGL drivers inner structure (particularly NVidia’s) answer the following question or advise something worthy.
I have the main thread that constantly performs scene rendering and the additional thread that load textures from the disk to memory. So I have two variants.
Get an RC for additional thread and share texture names with main thread RC. Call glTexImage* from the additional thread absolutely simultaneously with any OpenGL call from the main thread.
Schedule some of the main thread working time for glTexImage* calls and not to create RC for additional thread.
What variant would be faster (for one, two CPU system)?
I’ve realized the first variant. It works Ok but very seldom some long stalls occur. The debuggin shows that both threads are in OpenGL in this moments.
So any comments, suitable facts or something.
May be list of OpenGL functions that must not be called simultaneously.
It’s better to have one RC since switching RC is costly. That’s in general.
If your aim is to do 2 glTexImage in parallel on your NVidia, then I don’t think there is any gain and using 2 RCs will give a performance hit.
Async disk read would help you but there is no asynch glTexImage. Of course it depnds on the actual driver implementation. 3D labs cards (Wildcat) is suppose to perform well with multiple RC. I dont know the details.
I had a similar system for background loading of whole scenes while rendering a scene - that included many calls to many glTexImage*
I used two RCs then, and I did not notice too much overhead, except for big textures upload, which caused some stalls, sometimes for about half a second.
I can’t see a way of avoiding these stalls while calling glTexImage … maybe starting with a blank image and uploading small parts of it using glTexSubImage could help to control stall granularity ?!
BTW, I had no problems with NVidia drivers and switching contexts - but I had problems with ATI drivers that caused some crashes - but it was in 2001 - it must work better now !
Yes, stalls are about half a second even less but for the aircraft simulator it’s rather annoying delay.
About starting with a blank image. Is it official feature that using NULL “data” parameter in glTexImage* results in proper texture allocation that could be followed by glTexSubImage* ? I could not find this statement in papers.
To V-man. Actually I don’t need asynch glTexImage*. Main thread just renders using texturing of course but it doesn’t call glTexImage*. The most close to glTexImage* call that main thread does is glCopyTexSubImage for environment maps updating that occur rather rare.
OK, I thought you wanted both threads to be uploading textures.
You just have to code and benchmark to really get your answer, cause I havent tried this.
Originally posted by GeorgeSarkisyan:
About starting with a blank image. Is it official feature that using NULL “data” parameter in glTexImage* results in proper texture allocation that could be followed by glTexSubImage* ? I could not find this statement in papers.
Yes, that’s true. I think it’s in the spec and also a performance recommendation in one NVidia paper.
Just allocate once like that and then use glTexSubImageXD to update the texels.
You will get a big performance hit if you dont do it this way.
As you incrementally populate the texture with some number of texels each frame, you might wish to populate the lower level mipmaps first. and simultaneously play with the GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL, so that your texture will at least begin to appear very quickly (if that’s what you want)