Window GPU build issues in Pascal cards about pbrt-v4 HOT 17 CLOSED

Could you please try the commit I just pushed and see if it helps? (You can also try this branch which is based on the current master and has the atomic patch included.)

from pbrt-v4.

Thanks for your reply, but PBRT-v4 uses std library modified by NVIDIA which is named "libcu++", supporting cuda::std::atomic and it cannot replace by std library std::atomic which is included in <atomic>
I think it must be solved by replace the atomic operation.

from pbrt-v4.

@mmp will know better, but AFAICT those atomics in particular are only used by the CPU and never by the GPU so it should be fine to use the ones from the regular standard library.

from pbrt-v4.

@neverfelly to be clear, is that with the latest version of pbrt? This check should in theory ensure that it only tries to use them for sm_70 and up oin Windows. (I can't test that myself locally, but it seems simple enough that it should be hard to have a bug in...)

And indeed, those atomics are all for GPU code, so can't be replaced with std::atomic.

from pbrt-v4.

I'm not sure we are talking about the same atomics: aren't https://github.com/mmp/pbrt-v4/blob/master/src/pbrt/gpu/accel.cpp#L211 and https://github.com/mmp/pbrt-v4/blob/master/src/pbrt/gpu/pathintegrator.cpp#L275 CPU-only atomics? There might still be a point to include <cuda/std/atomic> rather than <atomic> to access those, that I am missing.

from pbrt-v4.

Doh! (Need more coffee..)

You're right, and yes, that would cause this. Fix pushed to the master branch--thanks!

from pbrt-v4.

No worries! (I should have been less lazy and swap GPUs to try it out on Pascal.)

from pbrt-v4.

Still getting an error about atomics on Pascal, when compiling optix.cu. It's sadly not giving much details as to where that header is coming from; I'll try to track it down.

9>------ Build started: Project: pbrt_lib, Configuration: RelWithDebInfo x64 ------
8>Building NVCC ptx file cuda_compile_ptx_1_generated_optix.cu.ptx
8>optix.cu
8>D:\Program Files\NVIDIA Corporation\CUDA\v11.0\Toolkit\include\cuda\std\detail/__atomic(10): fatal error C1189: #error:  "CUDA atomics are only supported for sm_60 and up on *nix and sm_70 and up on Windows."
8>CMake Error at cuda_compile_ptx_1_generated_optix.cu.ptx.RelWithDebInfo.cmake:212 (message):
8>  Error generating
8>  D:/Builds/pbrt-v4/cuda_compile_ptx_1_generated_optix.cu.ptx

from pbrt-v4.

Found the issue: optix.cu ends up including workqueue.h but does not define PBRT_IS_WINDOWS and so the added atomics check has no effect. PBRT_IS_WINDOWS and other such defines are defined on line 299+, way after the macro for compiling to PTX and embedding it is defined (lines 186 through 202).

from pbrt-v4.

Yep, ugh--that one optix.cu file is compiled in its own way, which leads to all sorts of troubles. I just pushed a fix to move that stuff earlier; hopefully that will do it.

from pbrt-v4.

You missed a small detail: you moved the definition of PBRT_DEFINITIONS around but it is still not used by the cuda_compile_ptx() macro. I tried simply passing in ${PBRT_DEFINITIONS} as an option, similar to ${PBRT_CUDA_DIAG_FLAGS} ,but that fails since the definitions are not prefixed by -D so nvcc considers them as additional input files. I also tried doing add_definitions (${PBRT_DEFINITIONS}) but that completely messes up everything else.

I'll send a MR with a rework of that part to not use the cuda_compile_ptx() macro but instead use the built-in support in CMake for CUDA, which avoids having to do those global includes and should hopefully help with those troubles you were mentioning.

that one optix.cu file is compiled in its own way, which leads to all sorts of troubles

from pbrt-v4.

I should add that manually passing -DPBRT_IS_WINDOWS results in PBRT compiling properly, and the code runs fine, rendering killeroo-gold.pbrt in 41 seconds on my GTX 1080 Ti. So once we get those definitions squared off, we should be good.

from pbrt-v4.

@neverfelly Merge request #31 should allow you to finally compile pbrt-v4 on Pascal (at least it does so locally).

from pbrt-v4.

(Looks like github automatically closed this based on the commit message.) Hopefully this does it for you, @neverfelly, but please re-open the issue if not.

from pbrt-v4.

This is still failing with the latest master.

from pbrt-v4.

I will re-check later today.

@atulitk Could you please share which version of Visual Studio and CMake you are using, as well as the whole compilation line with nvcc that is failing (or all build messages associated to optix.cu)?

from pbrt-v4.

Could you please give the code in #65 a try? There seems to be an issue with the Visual Studio CUDA integration that prevents host definitions from being passed along when compiling device code, leading to this issue.

from pbrt-v4.