# Why Optix Samples run incredibly slow?
**URL:** https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316
**Category:** OptiX
**Created:** [February 9, 2024, 12:45am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316 "2024-02-09T00:45:54Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@fatecasino](https://forums.developer.nvidia.com/u/fatecasino)
#### Post date: [February 9, 2024, 12:45am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316/1 "2024-02-09T00:45:54Z")
My Optix Samples run really slow…0.3fps
I haven’t modified the code apart from using the – **no-gl-interop** argument because the samples could not run without using it. I have the latest version of the Nvidia drivers on a win10 64bit machine.
Thanks!
---
### Author:  [@dhart](https://forums.developer.nvidia.com/u/dhart)
#### Post date: [February 9, 2024, 2:29am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316/2 "2024-02-09T02:29:28Z")
Are you running a debug build, or have validation mode enabled? OptiX always runs very slowly when device debugging is enabled. Or maybe you’re using a 2nd GPU not connected to your display, which usually requires disabling gl-interop IIRC, and something has gone wrong with the PCI transfer speeds?
–
David.
---
### Author:  [@fatecasino](https://forums.developer.nvidia.com/u/fatecasino)
#### Post date: [February 9, 2024, 2:51am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316/3 "2024-02-09T02:51:17Z")
thanks for your response, indeed, I am running on debug mode, but the other thing you mention has just reminded me that my nvidia is new, but my mobo is…pretty old! The pci speed must be slow, I’ll check it out to see it.
I will also run the samples on release mode to see the difference. As about the second video card, it is an onboard video card. Do you think that this might be the reason I am getting the gl-interop problem? Is there something I could do about it?
---
### Author:  [@dhart](https://forums.developer.nvidia.com/u/dhart)
#### Post date: [February 9, 2024, 4:30am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316/4 "2024-02-09T04:30:17Z")
I believe GL-interop only works when the OptiX GPU and display GPU are the same GPU - the two contexts have to be on the same device for GL-interop to work. So it’s totally normal to have to use `--no-gl-interop` when you have 2 GPUs.
I’m guessing if the debug build was the main issue, you don’t need to worry too much about your PCI setup, but FWIW, there are some utils to help you diagnose any PCI bandwidth issues. Check out `nvidia-smi topo -h`. IIRC there might also be a CUDA sample that measures and reports bandwidth across the different links in your system.
–
David.
---
### Author:  [@droettger](https://forums.developer.nvidia.com/u/droettger)
#### Post date: [February 9, 2024, 7:40am UTC](https://forums.developer.nvidia.com/t/why-optix-samples-run-incredibly-slow/282316/5 "2024-02-09T07:40:34Z")
If you remove the NVCC option which builds debug device code (-G) from the OptiX SDK example build process, the OptiX kernels will be as fast as in release mode while you still can debug your host code the same way in debug targets.
This post describes how: [https://forums.developer.nvidia.com/t/a-problem-when-i-want-to-createmodule/276228/2](https://forums.developer.nvidia.com/t/a-problem-when-i-want-to-createmodule/276228/2)
My [OptiX example framework](https://forums.developer.nvidia.com/t/optix-advanced-samples-on-github/48410/4) always builds release device code by default for both release and debug targets.
If the OpenGL context of your application is not running an NVIDIA implementation, then there cannot be CUDA-OpenGL interop with the device running the OptiX/CUDA raytracing code.
There are multiple ways to solve that:
The best would be to change the OpenGL pixelfomat selection to not use the standard Windows functions but the OpenGL WGL extensions to enumerate all pixelformats and pick one which is provided by the NVIDIA driver implementation.
Using these WGL functions instead of the Windows `ChoosePixelFormat`:
[https://github.com/KhronosGroup/OpenGL-Registry/blob/ca491a0576d5c026f06ebe29bfac7cbbcf1e8332/api/GL/wgl.h#L297C13-L297C42](https://github.com/KhronosGroup/OpenGL-Registry/blob/ca491a0576d5c026f06ebe29bfac7cbbcf1e8332/api/GL/wgl.h#L297C13-L297C42)
Since the OptiX examples use GLFW as window framework there is probably also a way to set some hints before creating the GLFW window to steer the application to use an NVIDIA OpenGL implementation.
Look at the **Window** and **Context** documentation here: [https://www.glfw.org/documentation.html](https://www.glfw.org/documentation.html)
Other methods would force either your application or your whole system to run the graphics on the discrete GPU.
Please have a look into the **NVIDIA Display Control Panel** application and look at the **3D Settings** → **Manage 3D Settings**.
(I’m running Quadro workstation boards and don’t know how this differs on GeForce. I’m currently looking at a laptop with integrated and discrete GPUs.)
There should be **Global** and **Program** settings tabs.
Inside the **Global** settings there is a **Preferred graphics processor** combo-box then.
Try changing that from **auto-select** to the **NVIDIA processor**.
(I have that set to auto-select and my OptiX programs work just fine.)
Inside the **Program** tab you can do the same for each executable individually.
I’m not sure if you need to do that for your executable or if it’s enough to do that for the Visual Studio executable as long as you start your applications from inside that.
Again, things work just fine out-of-the box on my iGPU + dGPU laptop but it’s a workstation system and with the provided information it’s unclear why your system behaves differently.