Question about input views

[tpadioleau]

Are users guaranteed that input views will not be modified ? I know that some backend cannot guarantee that for R2C or C2R transformations. What about KokkosFFT ?

I tried to pass a Kokkos::View<const Kokkos::complex<double>*> as an input view but it failed to compile.

[yasahi-hpc]

As you said, some backend may modify the input, so we cannot always ensure that.
But we may do that for some backends.

I tried to pass a Kokkos::View<const Kokkos::complex<double>*> as an input view but it failed to compile.

What errors did you get?

[tpadioleau]

As you said, some backend may modify the input, so we cannot always ensure that. But we may do that for some backends.

Yes but then the question is how to inform the user ? We can add something in the documentation but that can easily be missed. Can we do something at the API level ? Can we use different functions in the backends to avoid having an input view that is in fact input/ouptut ?

What errors did you get?

[  7%] Building CXX object examples/01_1DFFT/CMakeFiles/01_1DFFT.dir/01_1DFFT.cpp.o
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/impl/Kokkos_ViewMapping.hpp(2479): error: no instance of overloaded "operator new" matches the argument list
            argument types are: (unsigned long, const Kokkos::complex<double> *)
          detected during:
            instantiation of "std::enable_if_t<std::is_default_constructible<_ValueType>::value, void> Kokkos::Impl::ViewValueFunctor<DeviceType, ValueType, false>::operator()(const Kokkos::Impl::ViewValueFunctor<DeviceType, ValueType, false>::ConstructTag &, size_t) const [with DeviceType=Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, ValueType=const Kokkos::complex<double>, _ValueType=const Kokkos::complex<double>]" 
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/Cuda/Kokkos_Cuda_Parallel_Range.hpp(63): here
            instantiation of "std::enable_if_t<<expression>, void> Kokkos::Impl::ParallelFor<FunctorType, Kokkos::RangePolicy<Traits...>, Kokkos::Cuda>::exec_range<TagType>(Kokkos::Impl::ParallelFor<FunctorType, Kokkos::RangePolicy<Traits...>, Kokkos::Cuda>::Member) const [with FunctorType=Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>, Traits=<Kokkos::CudaSpace::execution_space, Kokkos::IndexType<int64_t>, Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>::ConstructTag>, TagType=Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>::ConstructTag]" 
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/Cuda/Kokkos_Cuda_Parallel_Range.hpp(80): here
            instantiation of "void Kokkos::Impl::ParallelFor<FunctorType, Kokkos::RangePolicy<Traits...>, Kokkos::Cuda>::operator()() const [with FunctorType=Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>, Traits=<Kokkos::CudaSpace::execution_space, Kokkos::IndexType<int64_t>, Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>::ConstructTag>]" 
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/Cuda/Kokkos_Cuda_KernelLaunch.hpp(87): here
            instantiation of "void Kokkos::Impl::cuda_parallel_launch_local_memory(DriverType) [with DriverType=Kokkos::Impl::ParallelFor<Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>, Kokkos::RangePolicy<Kokkos::CudaSpace::execution_space, Kokkos::IndexType<int64_t>, Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>::ConstructTag>, Kokkos::CudaSpace::execution_space>]" 
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/Cuda/Kokkos_Cuda_KernelLaunch.hpp(347): here
            instantiation of "std::decay_t<decltype((<expression>))> Kokkos::Impl::CudaParallelLaunchKernelFunc<DriverType, Kokkos::LaunchBounds<0U, 0U>, Kokkos::Impl::Experimental::CudaLaunchMechanism::LocalMemory>::get_kernel_func() [with DriverType=Kokkos::Impl::ParallelFor<Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>, Kokkos::RangePolicy<Kokkos::CudaSpace::execution_space, Kokkos::IndexType<int64_t>, Kokkos::Impl::ViewValueFunctor<Kokkos::Device<Kokkos::CudaSpace::execution_space, Kokkos::CudaSpace::memory_space>, const Kokkos::complex<double>, false>::ConstructTag>, Kokkos::CudaSpace::execution_space>]" 
/local/home/tpadiole/spack-0.22.2/var/spack/environments/ddc-cuda/.spack-env/view/include/Cuda/Kokkos_Cuda_KernelLaunch.hpp(691): here
            [ 7 instantiation contexts not shown ]
            instantiation of "Kokkos::View<DataType, Properties...>::View(const Label &, std::enable_if_t<Kokkos::Impl::is_view_label<Label>::value, const size_t>, size_t, size_t, size_t, size_t, size_t, size_t, size_t) [with DataType=const Kokkos::complex<double> *, Properties=<Kokkos::Cuda::array_layout, Kokkos::CudaSpace::memory_space, Kokkos::MemoryTraits<0U>>, Label=char [4]]" 
/local/home/tpadiole/Codes/kokkos-fft/common/src/KokkosFFT_padding.hpp(98): here
            instantiation of "void KokkosFFT::Impl::crop_or_pad_impl(const ExecutionSpace &, const InViewType &, OutViewType &, KokkosFFT::shape_type<1UL>) [with ExecutionSpace=execution_space, InViewType=Kokkos::View<const Kokkos::complex<double> *, execution_space>, OutViewType=Kokkos::View<const Kokkos::complex<double> *, Kokkos::Cuda::array_layout, Kokkos::CudaSpace::memory_space, Kokkos::MemoryTraits<0U>>]" 
/local/home/tpadiole/Codes/kokkos-fft/common/src/KokkosFFT_padding.hpp(352): here
            instantiation of "void KokkosFFT::Impl::crop_or_pad(const ExecutionSpace &, const InViewType &, OutViewType &, KokkosFFT::shape_type<DIM>) [with ExecutionSpace=execution_space, InViewType=Kokkos::View<const Kokkos::complex<double> *, execution_space>, OutViewType=Kokkos::View<const Kokkos::complex<double> *, Kokkos::Cuda::array_layout, Kokkos::CudaSpace::memory_space, Kokkos::MemoryTraits<0U>>, DIM=1UL]" 
/local/home/tpadiole/Codes/kokkos-fft/fft/src/KokkosFFT_Transform.hpp(95): here
            instantiation of "void KokkosFFT::Impl::fft_exec_impl(const PlanType &, const InViewType &, OutViewType &, KokkosFFT::Normalization) [with PlanType=KokkosFFT::Impl::Plan<execution_space, const Kokkos::View<const Kokkos::complex<double> *, execution_space>, Kokkos::View<Kokkos::complex<double> *, execution_space>, 1UL>, InViewType=Kokkos::View<const Kokkos::complex<double> *, execution_space>, OutViewType=Kokkos::View<Kokkos::complex<double> *, execution_space>]" 
/local/home/tpadiole/Codes/kokkos-fft/fft/src/KokkosFFT_Transform.hpp(147): here
            instantiation of "void KokkosFFT::fft(const ExecutionSpace &, const InViewType &, OutViewType &, KokkosFFT::Normalization, int, std::optional<std::size_t>) [with ExecutionSpace=execution_space, InViewType=Kokkos::View<const Kokkos::complex<double> *, execution_space>, OutViewType=Kokkos::View<Kokkos::complex<double> *, execution_space>]" 
/local/home/tpadiole/Codes/kokkos-fft/examples/01_1DFFT/01_1DFFT.cpp(31): here

[tpadioleau]

In our API, I find that

const InViewType& in, OutViewType& out

is a bit confusing for non-expert users. It looks like an API for unique owning containers like std::vector. I am afraid that a user could rapidly interpret this as in will never be modified because it is passed by const& and out might be modified because it is passed by non-const &.

[yasahi-hpc]

If I remembered, input data are unchanged except for HIPFFT.
I guess there are two solutions.

1. If input view has a const value type, allocate an internal buffer. This should be applied to HIPFFT backend only.
2. Drop HIPFFT support and allow to take an input view with a const value type.

[tpadioleau]

We have: https://docs.nvidia.com/cuda/cufft/index.html#data-layout

Out-of-place complex-to-real FFT will always overwrite input buffer. For out-of-place transforms, input and output sizes match the logical transform non-redundant size and size, respectively.

[yasahi-hpc]

We have: https://docs.nvidia.com/cuda/cufft/index.html#data-layout

Out-of-place complex-to-real FFT will always overwrite input buffer. For out-of-place transforms, input and output sizes match the logical transform non-redundant size and size, respectively.

I guess it refers to an internal buffer inside a Plan instance, but I am not 100 % sure

[tpadioleau]

I guess it refers to an internal buffer inside a Plan instance, but I am not 100 % sure

I don't understand why you interpret it like this ?

[yasahi-hpc]

For example, they explain about buffers in Fourier Transform Setup.
As found at the beginning of Data Layout, they call input and output as data.
If I remembered correctly, cufft did not modify the input data for out-of-place transforms.

[tpadioleau]

In my opinion they use both "data" and "buffer" to refer to inputs and outputs.

[yasahi-hpc]

That is confusing. If that is the case, we cannot guarantee a constant input for R2C and C2R transforms.

[tpadioleau]

Let's test to see if it is true or not

[yasahi-hpc]

Unfortunately, it changed the input for C2R and Z2D.

[tpadioleau]

ok :/