LuxCoreRender Forums

Introduction

The support for CUDA image pipeline (instead of OpenCL) is now available on sources after the merge of "cuda_imagepipeline" branch. Having CUDA support, instead of OpenCL, for the image pipeline is not particularly useful but it was a perfect test case to check if it was possible to add to the existing PATHOCL code (C++ and OpenCL) the support for CUDA (and than RTX). It is doable and it works.

New LuxRays role

LuxRays was originally written to support old Lux hybrid rendering (i.e. GPU does ray/triangle intersections and CPU everything else). It is now useless and the code has been removed. The new LuxRays role is to have an abstraction layer over the GPUs to write the code once and to run both on OpenCL and CUDA.
The current implementation of a generic HardwareDevice, with OpenCLHardwareDevice and CUDAHardwareDevice implementations, allows this.

Vulkan, Metal, etc.

While I don't plan to write a LuxRays VulkanHardwareDevice or a MetalHardwareDevice implementation, it is now possible and if someone wants, be my guest. This open the door to a support for Vulkan, Metal, etc. too in a future.

CUDA driver API, not CUDA

Technically, I'm not using CUDA (i.e. nvcc custom compiler, etc.), I'm using CUDA driver API and NVRTC (i.e. NVIDIA run-time compiler). It is slightly lower level version of "CUDA": it is just a library to link, no requirement for a special compiler version, etc. It is a lot easier to use and support in our context.

"OpenCL" is now "HardwareDevice"

It doesn't make sense anymore to talk directly of OpenCL because the same code runs also on CUDA so the term has been replaced in Film code by "Hardware Device" term (and HW abbreviation). The same will happen to all other code. For instance, PATHOCL will become PATHHW in a future, etc.

PATHHW

The really magic will happen when the same procedure will be applied to PATHOCL code. It is a LOT more code than OpenCL image pipeline support but, now, it looks like something viable and doable. I hope to have CUDA rendering support in v2.4 and RTX support in v2.5.

You're awesome

This is very inspiring to see your hardwork. Another good reason to stay at home and be there when all this lift off

Wow...

So "soon" we might see if luxcore on cuda is going to be faster than on opencl? Or is this not an accurate comparison to make?

And by ~2.5 we might even see a realtime optix denoising on top of optix raytracing...

lacilaci wrote: Mon Mar 30, 2020 4:27 pm So "soon" we might see if luxcore on cuda is going to be faster than on opencl?

If NVIDIA has not crippled its OpenCL drivers, the performance should be about the same ... IF ...

We will see, anyway the motivation beyond this work is all in having access to NVIDIA-only goodies like RTX, Optix, etc. There are also a lot of new options/features I can look into that may improve performances (even without considering RTX/Optix). With CUDA, you have a lot more control on the hardware.

lacilaci wrote: Mon Mar 30, 2020 4:27 pm Or is this not an accurate comparison to make?

It is going to be the best comparison you can have to know if OpenCL is crippled by NVIDIA: it will run exactly the same C code on OpenCL and CUDA on exactly the same hardware. Same hardware, same software, if CUDA is faster...

lacilaci wrote: Mon Mar 30, 2020 4:27 pm And by ~2.5 we might even see a realtime optix denoising on top of optix raytracing...

I expect something int 2-4 range with Optix on RTC hardware and geometry heavy scenes.

I think I have not said a single thing on this, but this is awesome