Vit operators
- [Add] OperatorTensors with Kernel implementaiton and unit-tests
- Erf
- Concat
- Gather
- ReduceMean
- Reshape
- Slice
- Transpose
- [Softmax kernel] update to support doing the operation on the attribute axis and not on a fixed one.
Merge request reports
Activity
6 * http://www.eclipse.org/legal/epl-2.0. 7 * 8 * SPDX-License-Identifier: EPL-2.0 9 * 10 ********************************************************************************/ 11 12 #ifndef AIDGE_CPU_OPERATOR_SLICEIMPL_FORWARD_KERNEL_H_ 13 #define AIDGE_CPU_OPERATOR_SLICEIMPL_FORWARD_KERNEL_H_ 14 15 #include "aidge/utils/Registrar.hpp" 16 17 #include "aidge/backend/cpu/operator/SliceImpl.hpp" 18 19 namespace Aidge { 20 template <class I, class O> 21 void SliceImpl_cpu_forward_kernel(const std::vector<DimSize_t> inputDims, @cmoineau this is what I was suggesting in our last exchange, what do you think of this kind of kernels, they are more generic (no need to add template for each dimension of input) and I think a bit faster (avoid nested loops), however they are not that intuitive (more time to code and understand). Feel free to tag people who might have an input on the matter.
Edited by Houssem ROUISHi, @pineapple did an implementation of the slice operator : https://gitlab.eclipse.org/eclipse/aidge/aidge_backend_cpu/-/blob/5a9d94c5263b5f36631e68ddc4746c35f7015d17/include/aidge/backend/cpu/operator/SliceImpl_forward_kernels.hpp so we will be able to compare both apporaches
I think we can open the discussion with @pineapple and @olivierbichler
changed this line in version 7 of the diff
added 2 commits
added 2 commits
added 4 commits
-
ce266959...1b56f5d0 - 3 commits from branch
eclipse/aidge:master
- e794c247 - Merge branch aidge_backend_cpu:master into vit_operators
-
ce266959...1b56f5d0 - 3 commits from branch
mentioned in epic &2
added 2 commits
requested review from @pineapple
added 25 commits
-
bfdf7407...fafa52d8 - 24 commits from branch
eclipse/aidge:master
- 4260ba9f - Merge branch 'master' of gitlab.eclipse.org:hrouis/aidge_backend_cpu into vit_operators
-
bfdf7407...fafa52d8 - 24 commits from branch
assigned to @hrouis
added AddFeature LanguageC++ StatusWIP labels
added 7 commits
-
25e14ea1...0703a9a0 - 5 commits from branch
eclipse/aidge:master
- 32d58662 - fix negative axis value for ReduceMean
- 45b0cd2e - Merge branch 'master' of...
-
25e14ea1...0703a9a0 - 5 commits from branch
added 4 commits
-
45b0cd2e...9676eac9 - 3 commits from branch
eclipse/aidge:master
- bc3f4fcb - Merge branch 'master' of...
-
45b0cd2e...9676eac9 - 3 commits from branch
added 3 commits
-
bc3f4fcb...602a9337 - 2 commits from branch
eclipse/aidge:master
- 5b1a492f - Merge branch aidge_backend_cpu:master into vit_operators
-
bc3f4fcb...602a9337 - 2 commits from branch
added 2 commits
I agree, there is no need to copy data here. However, such function doesn't need to be called each time in
forward()
. Setting the output Tensor's implementation pointer to the input's implementation pointer could be done inforwardDims()
(hence incomputeOutputDims()
). At this stage, the implementation is already set assetBackend()
has been previously called.Or maybe we should not mix Operator's functions and OperatorImpl's functions?
Edited by Maxence NaudThis discussion has been transfered to the issue #4 (closed) as it more wildly talks about in-place operations.
added 38 commits
-
764923ca...cc621da3 - 37 commits from branch
eclipse/aidge:master
- f4c43da9 - Merge branch 'master' of...
-
764923ca...cc621da3 - 37 commits from branch
added 3 commits
-
05c3fd5c...67679c82 - 2 commits from branch
eclipse/aidge:master
- 51ea7d74 - Merge branch aidge_backend_cpu:master into vit_operators
-
05c3fd5c...67679c82 - 2 commits from branch
added StatusReview Ready label and removed StatusWIP label
added StatusWIP label and removed StatusReview Ready label
added 15 commits
-
03a58652...e4fb24ee - 14 commits from branch
eclipse/aidge:dev
- 7215ade7 - Merge branch 'dev' into vit_operators
-
03a58652...e4fb24ee - 14 commits from branch
enabled an automatic merge when the pipeline for 7215ade7 succeeds
mentioned in issue #4 (closed)
added IssueBug 🐛 label
- Resolved by Maxence Naud
As indicated by the Windows CI, there is a 'STATUS_STACK_BUFFER_OVERRUN' indicated by exit code 0xc0000409 that prevents a merge of the branch.
I am currently working on it.
Edited by Maxence Naud
removed IssueBug 🐛 label
added StatusReview Ready label and removed StatusWIP label
mentioned in commit 8521b218
mentioned in merge request !50 (merged)