RT_ERROR_INVALID_SOURCE when using sm_61

When compiling with sm_61 architecture, most OptiX samples (advanced samples as well) throw an error (RT_ERROR_INVALID_SOURCE (1287)) on the call to rtContextValidate.
For example: optixGlass from the advanced samples (and my own project is based off that).
On the other hand, optixProgressivePhotonMap works fine.

How to duplicate this behaviour:

  1. Edit line 147 of CMakeLists.txt in the optix_advanced_samples-master\src directory: change sm_30 to sm_61.
  2. Follow the instructions in INSTALL-WIN.txt.
  3. Open OptiX-Advanced-Samples.sln and build the solution.
  4. Debug optixGlass.


  • Windows 10 64 bit
  • Visual Studio 2015
  • OptiX 4.1.1
  • CUDA Toolkit 8
  • GeForce GTX 1080

Is this a bug, or should I make additional modifications to be able to use sm_61?
(Or something above sm_35, that’s the top I’ve been able to use, but it didn’t speed up my application.)

Thanks for the report. We’ll try to reproduce this in-house.
So far optixGlass simply works with sm_61 PTX input on my Quadro P6000 and 385.69 display drivers though.
What is your display driver version? Maybe update to the newest available.

There is not really a need to use the newest available streaming mutlit-processor version as target for your OptiX PTX code generation, especially not when you want your OptiX program to run on the older supported GPU architectures as well. Simply keep it on sm_30 and it will run on Kepler and newer GPUs.

The last time I saw an invalid source error reported here was either using the incorrect *.ptx files inadvertently or when CUDA 8.0 decided to do dead code elimination on callable programs:

Hi Detlef, thanks for the quick reply.

I’m using the latest driver (385.69).
I don’t have callable programs in my code, and I didn’t make any modifications besides the aforementioned, so i think the issue is neither of the ones you mentioned.

So you’re saying that using sm_61 won’t make my code run any faster on a Pascal GPU?

Yes, I wouldn’t expect dramatic improvements from using different SM versions at that stage.
I’m always using sm_30 with OptiX 4 versions to be able to run my apps on Kepler and beyond.
OptiX is rewriting the code anyway, tags it with the currently underlying GPU’s SM version, and the PTX assembler and final microcode generation will take care of more optimizations.

I would worry more about performance on the algorithmic side of things when using OptiX.
Also check the OptiX Programming Guide Chapter 11 for general performance advice.

I see, thanks for the help! I’ll stick to sm_30.
I’ll definitely make improvements on the algorithmic side, I just thought that using the latest SM version might be an easy step up.