Fix/cuda shuffle changes

[griwodz]

Intrinsic functions __shfl_* as well as _any, _all and _ballot were replaced by more flexible _sync and _async version with CUDA 9. Those make sense with more recent CCs that allow the use of these functions even if some threads of a warp are already dead. We support older CCs as well and cannot rely on such features.

Importing a set of macros from PopSift that hide this difference between CUDA SDKs <9 and >=9.

[griwodz]

I fetched these changes from PopSift while working on the update_cudaCub branch because I couldn't find any real errors in all the warnings. Made this separate PR because it's not really related to Cub.

[simogasp]

Hi @griwodz ,

please also add this in ./cmake/config.hpp.in towards the end (line 30)

#ifdef CCTAG_WITH_CUDA

   #define CUB_CDP

--> to add
    #ifndef CCTAG_HAVE_SHFL_DOWN_SYNC
    #cmakedefine CCTAG_HAVE_SHFL_DOWN_SYNC
    #endif
-->
#endif

so that the definition is also up-to-date in the generated config.hpp

[simogasp]

this should go only in the case if CCTAG_WITH_CUDA is ON, as it can be only active on cuda code, am I right?
If so, it should be move up at line 116

  target_compile_definitions(CCTag
                         PUBLIC -DCCTAG_WITH_CUDA -DCUB_CDP
                         PRIVATE ${TBB_DEFINITIONS})

  if(CCTAG_HAVE_SHFL_DOWN_SYNC)
    target_compile_definitions(CCTag PRIVATE "-DCCTAG_HAVE_SHFL_DOWN_SYNC")
  endif()

[griwodz]

Hmm. The generated cctag_config.hpp has so far been ignored in the CCTag code. I understand that it's relevant for distributing CCTag but isn't it reasonable to use the same file inside CCTag as well as soon as we start using it?

Assuming that the answer is yes, I've added an include_directories() so that it is actually visible during compilation. But of course, when we start using cctag_config, then it's redundant to have target_compile_definitions as well.

[simogasp]

yes the cctag_config.hpp is ignored in the code because everything is managed by cmake (it propagates the definitions even when the library is used as third pary like in AliceVision).
But nevertheless, it is better to have for people that may not use cmake as building system.
At least they can include that before any other cctag header.
So I agree that it is not much useful in our configuration but it's better to have in the installed version.
For this reason please remove the include_directories() because we don't need that to be visible when building with cmake. FYI, the correct way to include that would be using

target_include_directories(<target> PUBLIC             
            $<BUILD_INTERFACE:${generated_dir}>  #this will include the generated dir *only* for in-tree building
            $<INSTALL_INTERFACE:include/> #this will include the the path where config.hpp is installed for using as third party

[simogasp]

BTW, the same holds for the version.hpp file, it is installed but never used, at least for the moment. In case we will need it in the code in the future then, again, we have to add that target_include_directories piece of code.

[griwodz]

I think we should start using our own generated config files at some point. The CXXFLAGS can in projects using CCTags can be manipulated as shown here: cmake-remove-a-compile-flag-for-a-single-translation-unit.
I'll try to remember that no-so-simple target_include_dir statement from above.

[griwodz]

I have a question:
cmake expects that a developer uses
#cmakedefine SOMETHING
and generates one of the following lines:
#define SOMETHING or /* #undef SOMETHING */

Is there any reason why our config.hpp.in file uses

#ifndef CCTAG_WITH_CUDA
#cmakedefine CCTAG_WITH_CUDA
#endif

?
I don't think that it's a good idea to allow users of the CCTag library to override these defines if/when this can activate branches in installed CCTag header files that are inconsistent with the actual code in the installed CCTag library. Or is it something that is required by an IDE?

[simogasp]

Yes, I agree it's a little be too overdoing, I don't remember the rationale behind it. I think it was a sort of safeguard to avoid redefining the macro in the same spirit as the define safeguards of the headers. It's embarrassing as it was me that did that and I forgot why... I must have been delirious...

[griwodz]

I undid the last 2 commits and followed your original recommended changes.

[simogasp]

thanks!