Can OptiX 7.6 run on Windows 11?

Hi,
My system version is Windows 11 with 12th gen Intel Core CPU and RTX 3080 Ti 16GB laptop GPU. I installed OptiX 7.6 and CUDA toolkit 11.8, and tried to run the OptiX samples offered by NVIDIA in the SDK dictionary after generating the project with CMAKE.
However, when I open the ‘*.cu’ file in Visual Studio 2022,it seems that the IDE recognize the functions like ‘optixGetRayTmax’ ‘optixGetWorldRayOrigin’ as undefined identifiers.
Besides, I found the samples work not very well on my PC, like the project ‘optixHair’, the fps only reached about 24 in Debug mode (VS can’t locate optixHairs.cu in other modes on my device) with default window size and view.
I wonder if OptiX doesn’t support Windows 11 well, for the release note only says that Windows 8/10 are supported. I would appreciate it if someone could give some useful solutions to my problem.
Thanks!

Any RTX graphics board will be fine for running OptiX 7 SDK examples. OptiX 7 supports all GPU architectures from Maxwell to Ada.

It will also work on Windows 11.

The main requirement to run OptiX programs on a system is a display driver supporting the OptiX 7 version you’re using. Which minimum display driver version is required can be found inside the OptiX Release Notes document. You’ll find the link to that directly beneath the OptiX download button on the developer.nvidia.com site.
Similar for the CUDA Toolkit version you use. When compiling the OptiX device code with a specific toolkit, make sure the display driver supports that CUDA version.
Well, simply have your display driver up to date and all should work together.

That the OptiX device functions get these wiggle underlines from Visual Studio 2022 Intellisense is normal. I have that as well. Pressing F12 (Go to Definition) when the cursor is on one of these functions works and goes to the optix_7_device_impl.h containing them. That header must not be included directly but is included automatically via the #include <optix.h> inside *.cu device code.
Not sure what Intellisense’s problem is there. You can ignore that. If anyone knows how to solve that, please chime in.

Never benchmark applications in debug mode!

The OptiX SDK examples are compiling PTX code with debug information which will result in comparably large and rather slow device code. The examples will also set the OptixModuleCompileOptions to not use any optimizations for debug targets.

The OptiX SDK examples display information about the device programs (via the OptixDeviceContextOptions logCallbackFunction and logCallbackLevel) and you’ll notice the has debug information output when running the debug executable. You don’t want that when benchmarking.
Instead build all examples in release mode and run them from the command prompt. They will report that the device program have no debug information.

Also note that some applications like the optixPathTracer shoot multiple paths per pixel per launch which isn’t giving the best first impression on performance. (Look for the launch parameter samples_per_launch. Try running that example with the command line option --launch-samples 1 if you think the default of 16 is slow.)

In general, with ray tracing performance comparisons, you need to know exactly what an application is doing to be able to judge its performance. You need at least to be aware of how many rays are shot per optixLaunch to know if some framerate is reasonable.

The OptiX API itself doesn’t know anything about displaying images on the screen. All it does is reading from and writing to CUDA device addresses.
The display of the ray traced images happens with OpenGL inside the OptiX SDK examples. The SwapBuffers call presenting the OpenGL back buffer to the visible screen is usually synchronized with the vertical refresh rate of the monitor (unless the applications are explicitly programmed with a swap interval of zero.)
For OpenGL based application benchmarks, please open the NVIDIA Display Control Panel, open the Manage 3D Settings page and set the Vertical Sync option to Off and apply the change and close the control panel.
That way OpenGL applications are not limited to the vertical refresh rate of the monitor, usually 60 Hz.

VS can’t locate optixHairs.cu in other modes on my device

Please try if running the executables from a command prompt with the current working directory at their target folder works. If yes, the working directory entry inside the Visual Studio debug settings is probably incorrect.
(Note that the examples hardcode their samples location into the executables, which is one of my pet peeves with that example framework.)

If you say it can’t locate a *.cu file, that means the compilation is done at runtime using NVRTC instead of compiling the device code from *.cu to *.ptx or *.optixir at compile time using NVCC?
Inside the CMake GUI please check if you have CUDA_NVRTC_ENABLED switched off and SAMPLES_INPUT_ENABLE_OPITXIR_SUPPORT and SAMPLES_INPUT_GENERATE_OPTIXIR switched on and SAMPLES_INPUT_GENERATE_PTX switched off.

Please have a look at the sticky posts of this OptiX developer forum for links to more OptiX 7 examples.

1 Like

Thank you for all the advice!
However, when I tried to run the executables from a command prompt, the program all crashed except the executables in the debug directory. It still says:
Caught exception: sutil::samplePTXFilePath couldn’t locate optixHair.cu for sample optixHair
after printing ‘bufferSizesGAS.outputSizeInBytes: 23804356 compacted size: 17158596’ and before printing’[ 4][ DISKCACHE]: Cache hit for key: …’ (this line can only be successfully printed in debug mode)
Still wondering why can I only run the executable in debug mode, I checked the CMake and made sure that I configured the options correctly as you said, and i cleared the whole directory and generated again, but the problem remains not solved.
Could you please give me more advice about how can I make the other modes work?

Hi @LPG,

Have you opened the solution in Visual Studio and chosen the Release profile before building & running? Can you launch the Release executables from Visual Studio instead of the command prompt?


David.

Hello,
I think that I have chosen the release profile for sure. I learnt more about the project later, and found that the the .cu files were not generated in the sutil.cpp searching directory. After that, I manually moved the files to the folder, and then I’ve become able to run the program in the release mode.
Thank you anyway!

That should not happen. I had been using the OptiX 7.6.0 SDK with CUDA 11. 8 and all executables worked where they had been built.

How did you set the CMake source and binary folders?

Inside the CMake GUI, the source folder needs to point to the top-most CMakeLists.txt in
<your_path>/OptiX SDK 7.6.0/SDK
The examples will not work when trying to build them with their CMakeFiles.txt in the individual example folders!

The build binaries output directory must be a different new folder, usually named “build”. I’m using the MSVS compiler version like
<your_path>/OptiX SDK 7.6.0/SDK/msvs2022

Then the executables land in
<your_path>\OptiX SDK 7.6.0\SDK\msvs2022\bin\Debug
and
<your_path>\OptiX SDK 7.6.0\SDK\msvs2022\bin\Release
and should work there out-of-the-box.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.