When I attach this as my miss program I get the following error
Unknown error (Details: Function "_rtContextLaunch2D" caught exception: Assertion failed: [1312602])
Playing with this program I found that if I comment the line where v is calculated, the program runs without errors.
I’m stuck in this for a day and still not able to find a solution. Is there a way to check where the problem is?
One observation is that when I run the tutorial example in the OptiX samples it works fine, however this is still a mistery to me since the code above is not even accessing the envmap texture.
I don’t know if it is sad or not when this happens but right after I post this question I found the problem. Comparing my CMake file with optix samples’ one I found that I wasn’t supplying the –use-fast-math flag. After I set this flags the program works fine.
That’s most likely an issue during program stitching. Hard to say without a reproducer.
Wild guesses:
If you build the tutorial yourself, does it work?
If the error is in line 8 above, what about sinf()?
Do you have --use_fast_math on your nvcc command line?
Could you try different SM versions as PTX target? (-arch=sm_20 etc.)
At which scope did you bind the environment sampler? Put it at the context.
If this doesn’t help it might make sense to send a reproducer in failing state to OptiX-Help to be able to file a bugreport. In that case the following information should be provided:
Operating system, 32/64-bit, graphics board, driver version, OptiX version, CUDA Toolkit version, targeted SM version, PTX bitness, (basically the nvcc command line).
Just in case, my spherical environment mapping miss program looks like this.
RT_PROGRAM void miss_spherical_environment()
{
const float3 R = theRay.direction; // Is normalized.
const float u = (atan2f(R.x, -R.z) + M_PIf) * 0.5f * M_1_PIf;
const float v = acosf(-R.y) * M_1_PIf;
// The seam u == 0.0 == 1.0 is in negative z-axis direction.
thePrd.color = make_float3(tex2D(sys_EnvironmentSampler, u, v));
thePrd.setMiss();
}
Edit: Damn, I had this answer open for too long. :-)
The sin() probably generated a double instead of a float instruction and OptiX could have failed to handle it.
If you build the tutorial yourself, does it work?
A: YES
If the error is in line 8 above, what about sinf()?
A: Any trigonometrical function cause the error
Do you have --use_fast_math on your nvcc command line?
A: Now I have.
Could you try different SM versions as PTX target? (-arch=sm_20 etc.)
A: I’m using sm_13. I have a GTX570 but if I use sm_20 I get the following error:
Parse error (Details: Function "_rtProgramCreateFromPTXFile" caught exception: (string): error: Cannot parse input PTX string phrt_generated_optix_pinhole_ray_gen.cu.ptx, line 7; : error : Unsupported .version 3.2; current version is '3.1'
At which scope did you bind the environment sampler? Put it at the context.
A: Yes, it was in the context.
Question: do I have to set --use-fast-math in order to OptiX work properly?
The question about the sinf() vs sin() was about the float vs. double version.
If --use_fast_math fixes the issue, it could have been a double instruction inside the PTX which shouldn’t happen with use_fast_math which will result in float instructions throughout the code.
If you look at the generated PTX you should be able to see the difference.
To the version error, that would be the PTX instruction set version.
Which CUDA toolkit version did you use?
I’d recommend 5.0. CUDA 5.5 is not yet supported. (See the OptiX release notes.)
I’ll leave the final question for an OptiX core developer.
I haven’t used OptiX without the --use_fast_math so far, and I’m explicitly not using any doubles in my OptiX programs. But if you used CUDA 5.5 this could be other root causes.
I know that OptiX doesn’t officially support CUDA 5.5 but I compile all sdk samples with CUDA 5.5 and they all work fine since I’m using sm_13 as my target architecture.
Unfortunately I can’t switch to CUDA 5.0 right now because I’m developing under Windows OS and I’m using some C++11 features that only VS2012 support. I have plans to support other systems but for now it is working fine.
Since using sm_13 is working for my development purposes, I’m going to keep developing until an official CUDA 5.5 support from OptiX to be released.
Right now even if you manage to compile OptiX samples with CUDA 5.5, there’s no official support and you might encounter undefined behavior during execution.
Good news are that OptiX CUDA 5.5 support is incoming. And so are VS2012 plus other interesting updates so you won’t have to wait for long.