Change Details

Support for the AO and bevel shader nodes has been one of the few remaining features that do not work with OptiX (T69800). Implementing this was originally not feasable, since it requires calling `optixTrace` from within the shading VM, but doing so was only allowed from inlined functions to the raygen program or continuation callables. Inlining the shading VM was not an option, and continuation callables were causing performance issues in this configuration, so the feature was left disabled. A while ago OptiX got support for calling `optixTrace` from within direct callables too however (which should be used sparingly, but exists for exactly features like shader raytracing in Cycles). This means converting the shading VM to use direct callables is all that is necessary to make it work. The problem however is that the way Cycles then uses direct callables is disadvantageous over normal CUDA noinline functions and currently comes with a performance hit (5-15%). This is likely going to be improved with future drivers, but to avoid performance regressions right now I implemented a workaround by using a separate kernel module when shader raytracing is active. This means by default nothing changes and the kernel is the exact same as before (kernel_optix.ptx), but if a scene makes use of AO or bevel shader nodes it now chooses a different kernel which has the shading VM converted to direct callables (kernel_optix_shader_raytrace.ptx). This renders slightly slower, but does render correctly now instead of throwing an error that the feature is not supported.

Support for the AO and bevel shader nodes has been one of the few remaining features that do not work with OptiX (T69800). Implementing this was originally not feasible, since it requires calling `optixTrace` from within the shading VM, but doing so was only allowed from inlined functions to the raygen program or continuation callables. Inlining the shading VM was not an option, and continuation callables were causing performance issues in this configuration, so the feature was left disabled. A while ago OptiX got support for calling `optixTrace` from within direct callables though. This means technically converting the shading VM to use direct callables is all that is necessary to make it work. The problem however is that the way Cycles then uses direct callables is disadvantageous over normal CUDA noinline functions and currently comes with a performance hit (5-15%). This is likely going to be improved with future drivers, but to avoid performance regressions right now I implemented a workaround by using a separate kernel module when shader raytracing is active. This means by default nothing changes and the kernel is the exact same as before (kernel_optix.ptx), but if a scene makes use of AO or bevel shader nodes it now chooses a different kernel which has the shading VM converted to direct callables (kernel_optix_shader_raytrace.ptx). So instead of throwing an error that the feature is not supported it renders correctly.

Support for the AO and bevel shader nodes has been one of the few remaining features that do not work with OptiX (T69800). Implementing this was originally not feasableible, since it requires calling `optixTrace` from within the shading VM, but doing so was only allowed from inlined functions to the raygen program or continuation callables. Inlining the shading VM was not an option, and continuation callables were causing performance issues in this configuration, so the feature was left disabled. A while ago OptiX got support for calling `optixTrace` from within direct callables too however (which should be used sparingly, but exists for exactly features like shader raytracing in Cycles)though. This means technically converting the shading VM to use direct callables is all that is necessary to make it work. The problem however is that the way Cycles then uses direct callables is disadvantageous over normal CUDA noinline functions and currently comes with a performance hit (5-15%). This is likely going to be improved with future drivers, but to avoid performance regressions right now I implemented a workaround by using a separate kernel module when shader raytracing is active. This means by default nothing changes and the kernel is the exact same as before (kernel_optix.ptx), but if a scene makes use of AO or bevel shader nodes it now chooses a different kernel which has the shading VM converted to direct callables (kernel_optix_shader_raytrace.ptx). This renders slightly slower, but does render correctly nowSo instead of throwing an error that the feature is not supported it renders correctly.