can optix 3.9.1 version work with cuda 9 or 10?
Please visit the OptiX site on developer.nvidia.com, log in to your account, follow the OptiX Get Started link, then scroll down to the All Older Versions link, click that, and read the OptiX Release Notes PDF below each of the individual OptiX versions you have compatibility questions about.
I did it before, however it is not clear if optix 3.9.1 is compatible with newer than 7.5 cuda versions.
The OptiX SDK 3.9.1 clearly say this:
Development Environment Requirements (for compiling with OptiX)
All Platforms (Windows, Linux):
CUDA Toolkit 4.0 – 7.5.
OptiX 3.9 has been built with CUDA 7.5, but any specified toolkit should work when compiling PTX for OptiX. If an application links against both the OptiX library and the CUDA runtime on Linux, it is recommended to use the same version of CUDA that was used to build OptiX.
At the time this SDK was released five years ago, there was no newer CUDA toolkit.
If you try building code for that with a newer CUDA Toolkit, it will most likely complain about the unsupported .version inside the PTX source code because the PTX parser was more restrictive in the past.
To be clear about the expectations. Nobody should be using that old OptiX SDK in 2020 anymore!
The OptiX API has not changed much from then to OptiX 6.5.0. There shouldn’t be problems in porting an OptiX 3.9.1 based application to OptiX 6.5.0 unless it was using Selector nodes which do not exist anymore.
Means if the original application is correctly implemented, then a recompile with new SDKs and toolkits and some small adjustments for the issues you’ve presented in your previous code excerpts should do.
With that you could also benefit from all improvements which happened on the software and hardware side in the last five years.
OptiX 6.5.0 should be way faster and supports RTX graphics boards. Still the only future proof SDK version is OptiX 7.
rtTrace inside an RT_CALLABLE_PROGRAM is complied successfully however it fails in running the program.
error : Unknown Value when trying to figure out pointer space for ray payload argument to rt_trace at: [ i64 %4 … …}
I think that it might be related to the declaration of bindless callable program.
can you give a simple code with the right declaration ?
thanks.
the callable program looks:
RT_CALLABLE_PROGRAM void InternalTrace(const float3& vOrigin, const float3& vDir, Scene_PolishPRD& prdPolish, Scene_InternalPRD& prdInternal)
{
if ( !m_bIgnoreInclusions )
{
if ( prdInternal.cInternalReflectionsCount <= m_cMaxIncReflections && prdInternal.eCurrHitType == Scene_InternalPRD::eMiss )
{
optix::Ray ray( vOrigin, vDir, RAYTYPE_SCENE_INTERNAL, m_fSafetyDist, prdPolish.fDist2NextFacet - m_fSafetyDist );
rtTrace( INCLUSIONS_TOP_OBJECT, ray, prdInternal );
if ( prdInternal.eCurrHitType != Scene_InternalPRD::eMiss )
{
prdInternal.fIntensityAtInclusion *= prdInternal.fOverallAccumulatedWeight * MaterialAttenuation( ray_intersection_dist );
m_IDsBuffer[vLaunchIndex] = static_cast<int>( prdInternal.uInclusionID );
}
}
}
prdInternal.fOverallAccumulatedWeight *= MaterialAttenuation( prdPolish.fDist2NextFacet );
prdInternal.cInternalReflectionsCount++;
}
according to the guide I should add beforehand the next declarations:
rtDeclareVariable(rtCallableProgramId<void(const float3, const float3, Scene_PolishPRD, Scene_InternalPRD)>, InternalTrace);
rtBuffer<rtCallableProgramId<void(const float3, const float3, Scene_PolishPRD, Scene_InternalPRD)>, 0> InternalTrace;
however, with these declarations the compilation fails and without them the execution fails.
I assume you’re using OptiX 6.5.0 now. This would be a different forum thread then, unrelated to OptiX 3.9.1 which doesn’t support this at all.
Generally, if possible you should avoid calling trace inside callable programs for performance reasons.
How many of the these InternalTrace() callable programs do you have?
Do you need to switch between them dynamically inside a single launch?
This is effectively the same explanation as in https://forums.developer.nvidia.com/t/unknown-value-when-trying-to-figure-out-pointer-space/74158/4
(That issue has been solved by moving to the OptiX SDK 7 which doesn’t have this issue due to the explicit continuation callables API in there.)
This OptiX Programming Guide chapter explains how to call rtTrace from callable programs including source code examples for the individual cases depending on how you declared the program ID variable (individually or in a buffer of callable program IDs)
Listing 4.43 in there explains exactly which two use cases of callable programs calling rtTrace will be handled by OptiX automatically and which other require additional instrumentation by the developer to indicate manually which callable programs are calling trace, with the functions rtMarkedCallableProgramId on device side and rtProgramCallsiteSetPotentialCallees on host side, so the OptiX can handle the additional resource management in a callable program hierarchy.
Your two lines will obviously not work together when using the same name.
It’s either one or the other, and the host code would need to be different when setting the individual callable program IDs inside a variable or in a buffer of callable program IDs.
I also wouldn’t name either the same as any of the callable programs assigned to those IDs.
Then both your failing declarations use the incorrect function signature, not matching the actual callable program, and the buffer has a zero dimension!
If your callable program function signature is
void InternalTrace(const float3& vOrigin, const float3& vDir, Scene_PolishPRD& prdPolish, Scene_InternalPRD& prdInternal)
then the declaration for a callable program ID variable holding that would be
rtDeclareVariable(rtCallableProgramId<void(const float3&, const float3&, Scene_PolishPRD&, Scene_InternalPRD&)>, myInternalTraceVariable);
or as a 1-dimensional buffer of callable program IDs (you had a zero for the dimension! One is also the default template argument):
rtBuffer<rtCallableProgramId<void(const float3&, const float3&, Scene_PolishPRD&, Scene_InternalPRD&)>, 1> myInternalTraceBufferOfCallableProgramIDs;
This is explained inside the programming guide chapter about callable programs.
My old OptiX Advanced Examples use four buffers with callable program IDs for lens shaders, light samplers, BSDF samplers and BSDF evaluation.
I do not call rtTrace from callable programs.
For example the lens shader in this buffer of callable program IDs and its call.
actually I’m using optix 5.1.
according to your answer this problem should disappear if I’ll use optix 7.
if this is the case I’ll make the change.
can you confirm?
OptiX 5.1 does not support rtTrace in callable programs.
That is only available since OptiX 6.0.0, as said at the beginning of the OptiX 6.5.0 programming guide chapter I cited first.
This should work in OptiX 6.5.0 as well when done right. That’s the latest available OptiX SDK for the old API.
This problem would not appear in OptiX 7 because the host and device API are completely different.
There you would be using the so called continuation callables which have been added for that purpose.
Still, it’s always better for performance if you can avoid using trace calls in callables. If you can calculate the necessary data you require for the next trace call in a direct callable program and then trace the ray afterwards, outside the callable, the performance is expected to be better. Or if you can inline everything and call the trace in the outermost scope, that would be even better.
Porting to the OptiX 7 API requires a rewrite of the host application and some systematic adjustments to the device programs.
I’m not using any OptiX version before 7.0.0 anymore and for many reasons. The major two are API performance and flexibility.
Follow the links in these threads for some explanations of the differences in the new OptiX 7 API:
https://forums.developer.nvidia.com/t/transitioning-from-optix-6-5-to-optix-7/147116/2
https://forums.developer.nvidia.com/t/optix-7-breaking-changes/156801/2
Just for reference, this is the OptiX 7 version of the same direct callables for the lens shaders and the call to it.
All callables are stored inside the Shader Binding Table (SBT) record in OptiX 7, so there is no buffer of bindless callable program IDs anymore.
thank you for your answer, however I still have another small question.
you said that Optix 5.1 does not support rtTrace in callable programs, however the program worked with optix 3.9.1 version without the variable declaration. is this problem is part of the upgrade to 5.1 version from 3.9.1?
The only possibility then would be if you have been using bound callable programs and not bindless callable programs. Your question was about rtCallableProgramId which are bindless callable programs.
I never use bound callable programs and forgot about that option. In the case of the bound callable programs, OptiX most likely inlined everything. Means it doesn’t actually remain a function, but is compiled into the caller which then would fulfill the required variable scoping for the trace call.
Looks like this is still present in OptiX 6.5.0, but the implementation of rtCallableProgram has been changed to a new template. Not sure if that works the same way.
Still trace cannot be called from bindless callable programs before OptiX 6.0.0, and since OptiX 7.0.0 this is all explicitly separated into direct callables and continuation callables.
How do we know if the callable program is bound or bindless?
From how it’s been assigned to variables and used on the device side.
Again described inside the OptiX Programming Guide
ok