|
10 | 10 | * into a single OpenCL kernel. This is much simpler than writing |
11 | 11 | * multi-operation kernels by hand. |
12 | 12 | * |
13 | | - * Because global GPU memory loads and stores are relativly slow compared to |
| 13 | + * Because global GPU memory loads and stores are relatively slow compared to |
14 | 14 | * calculations in a kernel, using one kernel for multiple operations is faster |
15 | 15 | * than using one kernel per operation. |
16 | 16 | * |
|
27 | 27 | * Element-wise functions can be added using one of the macros in |
28 | 28 | * `elt_functions.hpp`. |
29 | 29 | * |
30 | | - * New kernel generator classes must satsify the conditions below: |
| 30 | + * New kernel generator classes must satisfy the conditions below: |
31 | 31 | * |
32 | 32 | * 1. The class must be derived from a class inheriting from `operation_cl`. |
33 | 33 | * Optionally, if the operation should support being assigned to, it can be |
34 | 34 | * derived from a class inheriting `operation_cl_lhs` instead. |
35 | 35 | * 2. It's parent template arguments should be set to derived type, type of |
36 | | - * scalar and types of any expression arguements. |
| 36 | + * scalar and types of any expression arguments. |
37 | 37 | * 3. Member type `Scalar` should be defined as scalar type of the result of |
38 | 38 | * the operation. |
39 | 39 | * 4. Member function `deep_copy` should make a copy of the expression. |
|
97 | 97 | * |
98 | 98 | * A new operation should also have a user-facing function that accepts |
99 | 99 | * arguments to the operation and returns the operation object. Arguments should |
100 | | - * be passed trough function `as_operation_cl` so that they are wrapped in |
| 100 | + * be passed through function `as_operation_cl` so that they are wrapped in |
101 | 101 | * operations if they are not operations themselves. If the operation defines |
102 | 102 | * `modify_argument_indices` this function should make copies of arguments by |
103 | 103 | * calling `deep_copy()` on them internally. |
|
0 commit comments