Add KOKKOS_FUNCTION etc. documentation #578
Conversation
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | ||
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | ||
| parallel constructs defined in compilation unit B. |
There was a problem hiding this comment.
How is that supposed to work with SYCL?
There was a problem hiding this comment.
"in conjunction" implies its not the only thing you need to do
There was a problem hiding this comment.
Hmm... I still find the last sentence more confusing then helpful and would wait with saying anything for functions functions used in separable compilarion/relocatable device code until after discussing kokkos/kokkos#5993.
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | |
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | |
| parallel constructs defined in compilation unit B. |
crtrott
force-pushed
the
add-kokkos-function-doc
branch
from
23ae6d4
to
293fd96
Compare
|
|
||
| This macro provides default capture clause and host device markup for lambdas. It is the equivalent of | ||
| ``[=] __host__ __device__`` in CUDA and HIP. | ||
| It is used than creating C++ lambdas to be passed to Kokkos parallel dispatch mechanisms such as |
There was a problem hiding this comment.
That sentence is weird.
I think that we should consider having some blanket wording that says that any function or lambda called within a kernel is required to be properly annotated.
There was a problem hiding this comment.
actually its not because if you generate inside a KOKKOS_FUNCTION you can't use KOKKOS_LAMBDA currently
| ----------------------- | ||
|
|
||
| This macro provides default capture clause and host device markup for lambdas created inside of class member functions. It is the equivalent of | ||
| ``[=, *this] __host__ __device__`` in CUDA and HIP, capturing the parent class by value instead of by reference. |
There was a problem hiding this comment.
Please add a data member being accessed in the lambda and show that it is an alternative to
Foo {
...
Data member_;
};
auto const& member = member_;
parallel_for(..., KOKKOS_LAMBDA(...){ ... member ... });
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | ||
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | ||
| parallel constructs defined in compilation unit B. |
There was a problem hiding this comment.
Hmm... I still find the last sentence more confusing then helpful and would wait with saying anything for functions functions used in separable compilarion/relocatable device code until after discussing kokkos/kokkos#5993.
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | |
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | |
| parallel constructs defined in compilation unit B. |
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | ||
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | ||
| parallel constructs defined in compilation unit B. |
There was a problem hiding this comment.
Similarly here.
| This macro is also used for non-templated free functions in conjunction with relocatable device code - | |
| i.e. if one wants to compile functions in some compilation unit A but call them from Kokkos | |
| parallel constructs defined in compilation unit B. |
There was a problem hiding this comment.
We need some warning here, because otherwise people will pepper everything with the KOKKOS_FUNCTION instead of KOKKOS_INLINE_FUNCTION and it will fail depending on how stuff is set up. This didn't used to be much of a problem because everyone was using KOKKOS_INLINE_FUNCTION by default. But for a while now some team members have strenuously complained about that so folks are moving away from it :-)
There was a problem hiding this comment.
But currently there is nothing special about relocatable device functions; they behave the same as free functions that might need KOKKOS_INLINE_FUNCTON.
There was a problem hiding this comment.
If you want a function which uses relocatable device code capability you can't mark it KOKKOS_INLINE_FUNCTION. Only if you mark it KOKKOS_FUNCTION will it use that compilation/link technique or?
There was a problem hiding this comment.
Yes, it's the same as for a regular inline function that can't be used in the same context.
| ``KOKKOS_DEDUCTION_GUIDE`` | ||
| ----------------------- |
There was a problem hiding this comment.
/home/runner/work/kokkos-core-wiki/kokkos-core-wiki/docs/source/API/core/macros-special/host_device_macros.rst:175: WARNING: Title underline too short.
``KOKKOS_DEDUCTION_GUIDE``
-----------------------
| ``KOKKOS_DEDUCTION_GUIDE`` | |
| ----------------------- | |
| ``KOKKOS_DEDUCTION_GUIDE`` | |
| -------------------------- |
| ``KOKKOS_DEDUCTION_GUIDE`` | ||
| ----------------------- | ||
|
|
||
| This macro is used to annotate deduciont guides. |
There was a problem hiding this comment.
| This macro is used to annotate deduciont guides. | |
| This macro is used to annotate user-defined deduction guides. |
No description provided.