Currently I’m optimizing application running on OptiX 6.5, and I noticed weird (from my point of view) behavior. What I’m doing:
Clear OptixCache (from /var/tmp)
Clear any precompiled PTX
Define a scene with one sphere, dummy raygen and dummy closest_hit.
Run rendering, wait for compilation, see black frame (as intended, camera is not tracing anything).
Define second scene with 5 spheres - same intersection, bbox, material. Also I define same raygen.
Run rendering with verbosity=3, and see, that cache misses both for raygen and closest_hit.
Is this desired Optix behavior (to cache compiled programs once per scene setup)? I always HIT cache when there is no output_buffer in raygen, but was unable to get always HIT in closest hit, even if file is reduced to:
Do you have any ideas what could be happening here? I’m using sm_86 and 470.161.03 driver. Cache works correctly if I run once compiled scene setup again (rerun host app).
Have you verified that you are passing the bit-exact same input to rtProgramCreateFromPTXString() in both cases? Is there anything else in your setup that changes between the first and second run, like buffers, variables, use of instancing, etc.? I mean are the extra spheres the only change, or are there any other slight differences? You mentioned defining a dummy closest_hit for the first run, is it swapped for a real closest_hit for the 5-sphere scene?
Also have you tried reproducing on an SDK sample? I tried optixPathTracer, and I can comment out parts of the scene (like the “tall block” for example), recompile the app, and still see a cache hit. There might be certain things about scene setup that could change compilation and trigger a cache miss, but generally speaking a change in the geometry only should exhibit no change in compilation and result in a cache hit.
Hello @dhart
Thank you for your prompt response. I am truly grateful to know that there is someone on the other end who cares and is willing to provide assistance. Kindly find my responses to your questions attached below:
“Have you verified that you are passing the bit-exact same input to rtProgramCreateFromPTXString() in both cases?”
Yes
“Is there anything else in your setup that changes between the first and second run, like buffers, variables, use of instancing, etc.?”
There are new geometry instances, materials and geometries for new spheres (with same programs)
“You mentioned defining a dummy closest_hit for the first run, is it swapped for a real closest_hit for the 5-sphere scene?”
All programs remains the same
"Also have you tried reproducing on an SDK sample? "
I will try and I will update initial post
“There might be certain things about scene setup that could change compilation and trigger a cache miss.”
Do you have any list/docs which points out changes wchich triggers miss?
We don’t have documentation for all of the cache trigger reasons. One of the reasons the cache can miss due to scene changes is heuristic scene-dependent variable specialization. If you’re in a position to share a reproducer privately, we could examine and report back on the exact reason for the unexpected cache miss. (The reproducer can be either in the form of a binary, or in the form of an OptiX trace capture.)
Is it feasible in your case to warm your cache with the exact same scene that will be rendered, or are you hoping and expecting to support scene changes without any recompilation? Depending on what you need, there may be additional guidance we can offer.
Obligatory plug for upgrading to OptiX 7 at some point. I’m sure you’re aware so forgive me, but for what it’s worth, the caching behavior in OptiX 7 is more controllable, predictable, and transparent from a user perspective, since you control specialization explicitly, and OptiX 7 doesn’t know anything about your scene structure at compile time. This is among other reasons why OptiX 7 can be easier to optimize.
Thank you for your response. Regarding sharing an example, I will contact our legal department and try to provide you with one. Regarding warming cache I hope to support scene changes without recompilation. I am aware that upgrading to OptiX 7.x is necessary in the near future. We have also commenced broader experiments using different setups. I am hopeful that we will be able to identify edge cases, and we will update you with the results once we have them.