I am creating an application that uses a bidirectional path tracer using Optix.
In my tracer, i also use except from the framebuffer 2-3 smaller buffers that store useful data for the application.
I have the following performance problem.
When the resolution of the image or the maximum path depth is high enough to drop the “FPS”(<–as it is in the path_tracer example, meaning samples per pixel per second.) below 1 then the GPU performance significantly drops even further . I am then getting a fluctuating GPU load % which varies between 20-90%
For example :
using the following settings : 990X990 framebuffer size and an extreme path depth of 10 , i get 1.15 fps and constant 100% gpu load
BUT when i increase the FB to 1000X1000 instead of getting something similar, the fps drops to 0.55 and gpu has a variable gpu load , from 0-90%.
Any suggestions/guidelines to combat this problem ?
thank you in advance!
PS i use a system with : 4core- i7-2600K @4.6GHZ , GTX 560ti 1GB and 4GB ram
With just 1GB VRAM you’re probably running out of GPU memory and OptiX starts paging.
Look at rtContextSetAttribute() and rtContextGetAttribute() inside the OptiX API Reference document. It explains how to check if paging is active, or how to force it off and fail if you run out of memory.
If this doesn’t happen with a bigger board, smaller model, or an acceleration structure builder which uses less memory (e.g. try Bvh instead of Sbvh) then that’s it.
First of all thank you for answering !
No i do not think it’s a memmory issue, i do not use more than 520-550MB vRam in total[including the ammount of memmory that is used by the OS] even with big models
Are there any other ideas?
Did you check that paging was not active in the slow case?
What’s your OS?
If this is Windows Vista or newer, there is a two second Timeout Detection and Recovery (TDR) mechanism in the OS, which means at 0.55 fps you’re almost hitting that.
i will check it tomorrow because i am not today where the PC is:-) my OS is Windows 8.1
Thank you and i will inform you tomorrow about any news
The problem is solved . It was not the Timeout Detection and Recovery nor the paging feature (both ACTIVE and FORCED_OFF indicators were FALSE).
The culprit was the stack size, it lowered it from 2700 to 2100 and the problem disappeared.