Simplify distance/detail to make is easier to dispatch to different kernel implementations #1142

ahendriksen · 2023-01-13T21:07:50Z

The pairwise distance metrics are quite varied. The table below summarizes the differences, in terms of

Epilog : whether the metric has a non-empty epilog operation.
Uses norms: whether the metric requires precalculation of the norms of the vectors.
Has params: whether the norm has additional parameters. The L2 metric, for instance, has the sqrt boolean parameter that determines whether to calculate the squared or actual distance.
Pre- & post-processing: For some metrics, the norms have to be precalculated. For other metrics, the input matrices are transformed before the kernel launch, and "untransformed" after.
Expensive inner loop: some metrics use pow, log or other expensive functions in the inner loop.
Depends on row-major: the calculation of some metrics depend on whether the input is row-major.
CUTLASS: some metrics have an implementation using CUTLASS and tensor cores.

Metric	Epilog	Uses norms	Has params	Pre- & post-processing	Expensive inner loop	Depends on row-major	CUTLASS
Canberra					x
Chebyshev (Linf)
Correlation	x	x (twice)	x (many)	compute norms		x
Cosine	x	x		compute norms			x
Hamming	x		x (k)
Hellinger	x			sqrt and square
Jensen Shannon	x				x
KL divergence	x		x (row major, x == y)	yes	x	x
L1
L2 expanded	x	x	x (sqrt)	compute norms			x
L2 unexpanded	x		x (sqrt)
Minkowski (Lp)	x		x (p)		x
Russel-Rao	x		x (k, 1/k)

To keep the complexity that results from all these differences in check, there are several layers between the public API and the kernel launch, each with their own responsibility.

Before

raft::distance::pairwise_distance takes distance type as a run-time argument and dispatches to raft::distance::detail::pairwise_distance_impl.
raft::distance::detail::pairwise_distance_impl allocates workspace as necessary and calls raft::distance::detail::distance
raft::distance::detail::distance defines a default final operation (the identity) and calls an overload of itself.
raft::distance::detail::distance (with fin_op) initializes a DistanceImpl zero-sized struct with the correct template arguments and runs the .run() method of the struct.
raft::distance::detail::DistanceImpl<DistanceType>.run() calls raft::distance::detail::XX_Impl.
raft::distance::detail::XX_Impl has the following responsibilities:
- Pre-compute norms if necessary
- Transform input if necessary
- If metric supports a CUTLASS operation, dispatch if necessary.
- Swap inputs if column-major.
- Based on runtime parameter row_major dispatch to function template raft::distance::detail::XX<bool row_major>
raft::distance::detail::XX based on alignment of input data dispatch to function template raft::distance::detail::XX_Impl<int veclen> (different overload of previous raft::distance::detail::XX_Impl)
raft::distance::detail::XX_Impl has the following responsibilities:
- Define core_op and epilog_op
- Define use_norms
- Launch kernel pairwiseDistanceMatKernel with correct launch parameters

Observations:

Steps 6 and 7 both convert a runtime value to a compile time constant (row-major layout and alignment).
Step 7 is repeated (copy pasted) for each metric.
Steps 7 and 8 do a lot of different things and the steps in between do relatively little.
Steps 1-5 do fairly little (but require a lot of boilerplate)

Proposal:

Collect as much of the runtime behavior of each metric in a distance_op that contains:
- The core_op
- The epilog_op
- The required shared memory
- Whether the inner loop is expensive (and thus loop unrolling should be curtailed)
Collect the runtime -> compile-time dispatch in one location (dispatch.cuh)
Collect kernel launching in one location
Remove some of the boilerplate in steps 1-5.

After

raft::distance::pairwise_distance takes distance type as a run-time argument, allocates workspace as necessary, and dispatches to raft::distance::detail::distance.
raft::distance::detail::distance defines a default final operation (the identity) and calls an overload of itself.
raft::distance::detail::distance (with fin_op) calls an overload of raft::distance::detail::distance_impl for the correct distance type.
raft::distance::detail::distance_impl has the following responsibilities:
- Pre-compute norms if necessary
- Initialize distance op with parameters as necessary, see below for more information.
- Transform input if necessary
- If metric supports a CUTLASS operation, dispatch if necessary.
- Dispatch to raft::distance::detail::distance_matrix_dispatch
raft::distance::detail::distance_matrix_dispatch has the following responsibilities:
- swap x, y matrices if column major
- dispatch to correct kernel based on run-time parameters row_major and vec_len
- Determine kernel policy based on parameters
- Call raft::distance::detail::pairwise_matrix
raft::distance::detail::pairwise_matrix launches the raft::distance::detail::pairwise_matrix_kernel with the correct launch parameters.

Distance_op
raft::distance::detail::ops::XX_distance_op [example] has the following responsibilities:

Take any parameters (sqrt, k, etc)
Define core_op and epilog_op
Define use_norms, expensive_inner_loop, and shared_mem_size().

Still TODO:

Rename Minkowski and Chebyshev to Lp and Linf.
Do something with this note in the comments: "if workspace is passed as nullptr, this will return in worksize, the number of bytes of workspace required", which is wrong.
Add a mechanism to limit duplicate compilation when a CUTLASS kernel is available. This is done in follow up PR Add dispatch based on compute architecture #1295.
Some distance_ops have additional template parameters. This must be cleared up.

ahendriksen · 2023-01-24T22:02:47Z

Reminder/TODO

make grid stride loop variables local variables instead of member variables.

See: #838 (comment)

ahendriksen · 2023-01-25T09:05:22Z

TODO: #838 (comment)

Also look at fused and maskedL2NN for shared memory calculations.

The calculation of the tile indices are now performed in ldgXY(). This will make it possible to remove all state related to the tile index out of the class in the next commit. Note that the calculation of the tile index can depend on which overloaded constructor is called(!)

This commit moves all grid and tile indexing logic into the caller. Contractions_NT is now only responsible for *intra*-tile indexing. Due to the complexity of the epilog function, the ldgNextGridStride function is not yet called from within the main loop. That is the next goal so that we have all the grid and tile indexing localized in the loop.

This commit removes the epilog function and moves its functionality into the run loop. The next step might be to see if the ldgNextGridStride() method has to be called the current location, or if performance is the same if its called at the start of the loop.

This results in subtle issues with non-square KernelPolicy, as found in fusedL2KNN.

This is more general than just for L1. Making use of it more is work in progress.

By adding yet another struct ^^

This did remove support for the CUTLASS kernels. Has to be put back.

I wasted a lot of time because I had not replaced the op::core() method of the l2_exp_distance_op after I copied it from l2_unexp_distance_op... If I copy something from the template and forget to fill it in, I get a compile error.

I am testing on CUDA 12, where it does not seem to work. Prior to my commits, the CUTLASS kernels were also not working. So not sure what's up. In any case: consider this untested.

ahendriksen · 2023-02-23T09:14:26Z

The CI error does not seem related to the changes in the PR:

2023-02-22T19:37:49.5526382Z   Error compiling Cython file:
2023-02-22T19:37:49.5533415Z   ------------------------------------------------------------
2023-02-22T19:37:49.5539691Z   ...
2023-02-22T19:37:49.5546449Z   # cython: language_level = 3
2023-02-22T19:37:49.5552762Z 
2023-02-22T19:37:49.5559417Z 
2023-02-22T19:37:49.5566630Z   from libcpp.memory cimport shared_ptr, unique_ptr
2023-02-22T19:37:49.5573013Z 
2023-02-22T19:37:49.5580739Z   from rmm._lib.cuda_stream_pool cimport cuda_stream_pool

Is there a way to rerun the CI without pushing an empty commit?

vyasr · 2023-02-23T22:24:52Z

@ahendriksen if you click on the "Details" button it will take you to the actions tab where you can use the "Re-run jobs" dropdown. See https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs for more info. I've queued up a rerun.

ahendriksen · 2023-02-24T09:04:30Z

Thanks! And thanks for linking to the docs. I will have a look to see what else I am missing.

cjnolet

I really like the idea of abstracting each unique distance formula into composable ops. In this case, not only does it allow us to specify and react differently to various performance conditions, but it allows us to capture the differences of the computations themselves in a single place. This is very much what we did w/ the sparse APIs as well- they are a series of composable operations that can be executed according to their needs (in the sparse case that's binary vs dot-product-based vs full-pairwise evaluation).

I think this looks great. I'd like to see the functions in the public API that accept explicit workspaces deprecated because the memory resource should be getting propagated through the raft::resources instance (and be controllable by the user). I think we have an opportunity to here to expand our developer guide as well. Otherwise, I'm completely on board w/ this change.

cpp/include/raft/distance/detail/distance_ops/template.cuh

cpp/include/raft/distance/distance.cuh

cpp/test/CMakeLists.txt

cpp/include/raft/distance/distance.cuh

tfeher

Thanks Allard for this PR! This looks great! I am very happy to see the reduction of code duplication. I have just a few smaller questions.

cpp/include/raft/distance/detail/distance_ops/canberra.cuh

cpp/include/raft/distance/detail/distance_ops/correlation.cuh

cpp/include/raft/distance/detail/distance_ops/kl_divergence.cuh

cpp/include/raft/distance/detail/distance.cuh

cpp/include/raft/distance/detail/pairwise_matrix/dispatch.cuh

cpp/include/raft/distance/detail/pairwise_matrix/kernel_sm60.cuh

Co-authored-by: Tamas Bela Feher <[email protected]>

tfeher

Thanks Allard for the updates! The PR looks good to me!

cjnolet · 2023-03-09T17:13:23Z

Just a heads up- we need to merge this cuml PR before this RAFT PR is merged, otherwise cuml will break downstream.

ahendriksen · 2023-03-09T18:31:08Z

Good catch. I should be more careful with the non-breaking label. Although that file has been deprecated for a couple of months now.

cjnolet · 2023-03-09T18:55:58Z

Good catch. I should be more careful with the non-breaking label. Although that file has been deprecated for a couple of months now.

No problem. To be fair, we had updated cuml in 23.02 to remove most of its uses of deprecated headers but this one slipped through the cracks. Before we merged this I just wanted to do a quick grep to be sure.

cjnolet

LGTM!

cjnolet · 2023-03-10T03:33:34Z

/merge

…ernel implementations (rapidsai#1142) The pairwise distance metrics are quite varied. The table below summarizes the differences, in terms of - Epilog : whether the metric has a non-empty epilog operation. - Uses norms: whether the metric requires precalculation of the norms of the vectors. - Has params: whether the norm has additional parameters. The L2 metric, for instance, has the `sqrt` boolean parameter that determines whether to calculate the squared or actual distance. - Pre- & post-processing: For some metrics, the norms have to be precalculated. For other metrics, the input matrices are transformed before the kernel launch, and "untransformed" after. - Expensive inner loop: some metrics use `pow`, `log` or other expensive functions in the inner loop. - Depends on row-major: the calculation of some metrics depend on whether the input is row-major. - CUTLASS: some metrics have an implementation using CUTLASS and tensor cores. <table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides"> <colgroup> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> <col class="org-left" /> </colgroup> <thead> <tr> <th scope="col" class="org-left">Metric</th> <th scope="col" class="org-left">Epilog</th> <th scope="col" class="org-left">Uses norms</th> <th scope="col" class="org-left">Has params</th> <th scope="col" class="org-left">Pre- & post-processing</th> <th scope="col" class="org-left">Expensive inner loop</th> <th scope="col" class="org-left">Depends on row-major</th> <th scope="col" class="org-left">CUTLASS</th> </tr> </thead> <tbody> <tr> <td class="org-left">Canberra</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Chebyshev (Linf)</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Correlation</td> <td class="org-left">x</td> <td class="org-left">x (twice)</td> <td class="org-left">x (many)</td> <td class="org-left">compute norms</td> <td class="org-left"> </td> <td class="org-left">x</td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Cosine</td> <td class="org-left">x</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">compute norms</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left">x</td> </tr> <tr> <td class="org-left">Hamming</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">x (k)</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Hellinger</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left">sqrt and square</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Jensen Shannon</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">KL divergence</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">x (row major, x == y)</td> <td class="org-left">yes</td> <td class="org-left">x</td> <td class="org-left">x</td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">L1</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">L2 expanded</td> <td class="org-left">x</td> <td class="org-left">x</td> <td class="org-left">x (sqrt)</td> <td class="org-left">compute norms</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left">x</td> </tr> <tr> <td class="org-left">L2 unexpanded</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">x (sqrt)</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Minkowski (Lp)</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">x (p)</td> <td class="org-left"> </td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> <tr> <td class="org-left">Russel-Rao</td> <td class="org-left">x</td> <td class="org-left"> </td> <td class="org-left">x (k, 1/k)</td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> <td class="org-left"> </td> </tr> </tbody> </table> To keep the complexity that results from all these differences in check, there are several layers between the public API and the kernel launch, each with their own responsibility. ## Before 1. `raft::distance::pairwise_distance` takes distance type as a run-time argument and dispatches to `raft::distance::detail::pairwise_distance_impl`. 2. `raft::distance::detail::pairwise_distance_impl` allocates workspace as necessary and calls `raft::distance::detail::distance` 3. `raft::distance::detail::distance` defines a default final operation (the identity) and calls an overload of itself. 4. `raft::distance::detail::distance` (with `fin_op`) initializes a `DistanceImpl` zero-sized struct with the correct template arguments and runs the `.run()` method of the struct. 5. `raft::distance::detail::DistanceImpl<DistanceType>.run()` calls `raft::distance::detail::XX_Impl`. 6. `raft::distance::detail::XX_Impl` has the following responsibilities: - Pre-compute norms if necessary - Transform input if necessary - If metric supports a CUTLASS operation, dispatch if necessary. - Swap inputs if column-major. - Based on runtime parameter `row_major` dispatch to function template `raft::distance::detail::XX<bool row_major>` 7. `raft::distance::detail::XX` based on alignment of input data dispatch to function template `raft::distance::detail::XX_Impl<int veclen>` (different overload of previous `raft::distance::detail::XX_Impl`) 8. `raft::distance::detail::XX_Impl` has the following responsibilities: - Define `core_op` and `epilog_op` - Define `use_norms` - Launch kernel `pairwiseDistanceMatKernel` with correct launch parameters **Observations**: - Steps 6 and 7 both convert a runtime value to a compile time constant (row-major layout and alignment). - Step 7 is repeated (copy pasted) for each metric. - Steps 7 and 8 do a lot of different things and the steps in between do relatively little. - Steps 1-5 do fairly little (but require a lot of boilerplate) **Proposal**: 1. Collect as much of the runtime behavior of each metric in a `distance_op` that [contains](https://github.com/ahendriksen/raft/blob/wip-refactor-distance/cpp/include/raft/distance/detail/distance_ops/canberra.cuh): - The core_op - The epilog_op - The required shared memory - Whether the inner loop is expensive (and thus loop unrolling should be curtailed) 2. Collect the runtime -> compile-time dispatch in one location ([dispatch.cuh](https://github.com/ahendriksen/raft/blob/486393eff4e0cf1d45ab9d7990b64d607e835d70/cpp/include/raft/distance/detail/pairwise_matrix/dispatch.cuh#L70)) 3. Collect kernel launching in one [location](https://github.com/ahendriksen/raft/blob/486393eff4e0cf1d45ab9d7990b64d607e835d70/cpp/include/raft/distance/detail/pairwise_matrix/kernel_sm60.cuh#L108) 4. Remove some of the boilerplate in steps 1-5. ## After 1. `raft::distance::pairwise_distance` takes distance type as a run-time argument, allocates workspace as necessary, and dispatches to `raft::distance::detail::distance`. 2. `raft::distance::detail::distance` defines a default final operation (the identity) and calls an overload of itself. 3. `raft::distance::detail::distance` (with `fin_op`) calls an overload of `raft::distance::detail::distance_impl` for the correct distance type. 4. `raft::distance::detail::distance_impl` has the following responsibilities: - Pre-compute norms if necessary - Initialize distance op with parameters as necessary, see below for more information. - Transform input if necessary - If metric supports a CUTLASS operation, dispatch if necessary. - Dispatch to `raft::distance::detail::distance_matrix_dispatch` 5. `raft::distance::detail::distance_matrix_dispatch` has the following responsibilities: - swap x, y matrices if column major - dispatch to correct kernel based on run-time parameters `row_major` and `vec_len` - Determine kernel policy based on parameters - Call `raft::distance::detail::pairwise_matrix` 6. `raft::distance::detail::pairwise_matrix` launches the `raft::distance::detail::pairwise_matrix_kernel` with the correct launch parameters. **Distance_op** `raft::distance::detail::ops::XX_distance_op` [[example]](https://github.com/ahendriksen/raft/blob/wip-refactor-distance/cpp/include/raft/distance/detail/distance_ops/canberra.cuh) has the following responsibilities: - Take any parameters (sqrt, k, etc) - Define `core_op` and `epilog_op` - Define `use_norms`, `expensive_inner_loop`, and `shared_mem_size()`. Still TODO: - [x] Rename Minkowski and Chebyshev to Lp and Linf. - [x] Do something with this note in the comments: "if workspace is passed as nullptr, this will return in worksize, the number of bytes of workspace required", which is wrong. - [x] Add a mechanism to limit duplicate compilation when a CUTLASS kernel is available. This is done in follow up PR rapidsai#1295. - [x] Some distance_ops have additional template parameters. This must be cleared up. Authors: - Allard Hendriksen (https://github.com/ahendriksen) - Corey J. Nolet (https://github.com/cjnolet) Approvers: - Tamas Bela Feher (https://github.com/tfeher) - Corey J. Nolet (https://github.com/cjnolet) URL: rapidsai#1142

This PR improves the ability to do dispatch based on compute architecture. It is a follow up to #1142. It has two goals: 1. Make it easier to specify which compute architectures a kernel is compatible with / should be compiled for. 2. Make it easier to compile a kernel only for the architectures for which it is used (if it is unused, the kernel should be empty). We have a specific use case in RAFT for this feature. For the L2 pairwise distance kernel we have a CUTLASS based implementation that works om SM80+ and a fallback kernel. Preferably, each kernel is only compiled for the architectures on which it is actually used. Authors: - Allard Hendriksen (https://github.com/ahendriksen) - Corey J. Nolet (https://github.com/cjnolet) Approvers: - Tamas Bela Feher (https://github.com/tfeher) - Corey J. Nolet (https://github.com/cjnolet) URL: #1335

github-actions bot added CMake cpp labels Jan 13, 2023

ahendriksen changed the title ~~[WIP] Refactor distance/detail~~ [WIP] Refactor distance/detail to make is easier to dispatch to different kernel implementations Jan 13, 2023

ahendriksen force-pushed the wip-refactor-distance branch from 6d78314 to d58f0f3 Compare January 13, 2023 21:23

github-actions bot removed the CMake label Jan 13, 2023

ahendriksen force-pushed the wip-refactor-distance branch from d58f0f3 to a213ef3 Compare January 13, 2023 21:27

ahendriksen changed the title ~~[WIP] Refactor distance/detail to make is easier to dispatch to different kernel implementations~~ [WIP] Simplify distance/detail to make is easier to dispatch to different kernel implementations Jan 13, 2023

cjnolet assigned ahendriksen Jan 22, 2023

ahendriksen mentioned this pull request Jan 25, 2023

Add MaskedL2NN #838

Merged

cjnolet added improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels Jan 26, 2023

ahendriksen added 17 commits February 8, 2023 14:56

pairwise_distance_base: Fix typo

a15d5fc

This results in subtle issues with non-square KernelPolicy, as found in fusedL2KNN.

Remove deprecated header

71c6da6

Replace lambdas by raft::void_op

4bbedf6

Use an operator for L1 distance

c3d1f6e

Add launch function

3e3478b

This is more general than just for L1. Making use of it more is work in progress.

l1: Replace run-time -> compile-time dispatch

264a9d2

pairwise matrix: move files into subdirectories

b232057

pairwise matrix: Untangle dispatching and kernel template parameters

06f6ffa

By adding yet another struct ^^

l2 unexp: Use pairwise matrix dispatch

2f41faa

l2 exp: Use pairwise matrix dispatch

7938614

This did remove support for the CUTLASS kernels. Has to be put back.

Add template for distance operator

7afe6cc

I wasted a lot of time because I had not replaced the op::core() method of the l2_exp_distance_op after I copied it from l2_unexp_distance_op... If I copy something from the template and forget to fill it in, I get a compile error.

Reenable cutlass-based kernels for CUDA 12.0

5fe3292

pairwise matrix l2: Add support for CUTLASS kernels

c623332

I am testing on CUDA 12, where it does not seem to work. Prior to my commits, the CUTLASS kernels were also not working. So not sure what's up. In any case: consider this untested.

Canberra: use dispatching mechanism

27511fc

cjnolet requested changes Mar 1, 2023

View reviewed changes

cpp/include/raft/distance/detail/distance_ops/template.cuh Show resolved Hide resolved

cpp/include/raft/distance/distance.cuh Show resolved Hide resolved

cpp/test/CMakeLists.txt Show resolved Hide resolved

cpp/include/raft/distance/distance.cuh Show resolved Hide resolved

tfeher requested changes Mar 6, 2023

View reviewed changes

ahendriksen and others added 4 commits March 6, 2023 17:59

Update cpp/include/raft/distance/detail/distance_ops/canberra.cuh

6467221

Co-authored-by: Tamas Bela Feher <[email protected]>

Update cpp/include/raft/distance/detail/distance.cuh

a83461e

Co-authored-by: Tamas Bela Feher <[email protected]>

Add note about alignment in case of byte input

393edf3

Fix

48a0c21

tfeher approved these changes Mar 7, 2023

View reviewed changes

cjnolet added 2 commits March 8, 2023 15:52

Merge branch 'branch-23.04' into wip-refactor-distance

393c546

Merge branch 'branch-23.04' into wip-refactor-distance

c9cbf2c

ahendriksen mentioned this pull request Mar 9, 2023

[FEA] Have pairwisedistancebase take a distance_op instead of two lambdas #1323

Closed

ahendriksen added 2 commits March 9, 2023 09:52

Add issue for TODO

569b2c2

Merge PR 1319 into wip-refactor-distance

46fd8e5

cjnolet added 2 commits March 9, 2023 13:56

Merge branch 'branch-23.04' into wip-refactor-distance

d089e80

Merge branch 'branch-23.04' into wip-refactor-distance

6d17ac4

cjnolet approved these changes Mar 10, 2023

View reviewed changes

cjnolet added 5 - Ready to Merge and removed 3 - Ready for Review labels Mar 10, 2023

rapids-bot bot merged commit e4aec7b into rapidsai:branch-23.04 Mar 10, 2023

This was referenced Mar 13, 2023

Fused L2 1-NN based on cutlass 3xTF32 / DMMA #1118

Merged

Add dispatch based on compute architecture #1335

Merged

ahendriksen deleted the wip-refactor-distance branch March 17, 2023 09:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify distance/detail to make is easier to dispatch to different kernel implementations #1142

Simplify distance/detail to make is easier to dispatch to different kernel implementations #1142

ahendriksen commented Jan 13, 2023 •

edited

Loading

ahendriksen commented Jan 24, 2023

ahendriksen commented Jan 25, 2023

ahendriksen commented Feb 23, 2023

vyasr commented Feb 23, 2023

ahendriksen commented Feb 24, 2023

cjnolet left a comment

tfeher left a comment

tfeher left a comment

cjnolet commented Mar 9, 2023

ahendriksen commented Mar 9, 2023

cjnolet commented Mar 9, 2023 •

edited

Loading

cjnolet left a comment

cjnolet commented Mar 10, 2023

Simplify distance/detail to make is easier to dispatch to different kernel implementations #1142

Simplify distance/detail to make is easier to dispatch to different kernel implementations #1142

Conversation

ahendriksen commented Jan 13, 2023 • edited Loading

Before

After

ahendriksen commented Jan 24, 2023

ahendriksen commented Jan 25, 2023

ahendriksen commented Feb 23, 2023

vyasr commented Feb 23, 2023

ahendriksen commented Feb 24, 2023

cjnolet left a comment

Choose a reason for hiding this comment

tfeher left a comment

Choose a reason for hiding this comment

tfeher left a comment

Choose a reason for hiding this comment

cjnolet commented Mar 9, 2023

ahendriksen commented Mar 9, 2023

cjnolet commented Mar 9, 2023 • edited Loading

cjnolet left a comment

Choose a reason for hiding this comment

cjnolet commented Mar 10, 2023

ahendriksen commented Jan 13, 2023 •

edited

Loading

cjnolet commented Mar 9, 2023 •

edited

Loading