Skip to content

AmgxPgm cuda/hip/omp implementation and matrix/array utils#695

Merged
yhmtsai merged 16 commits into
developfrom
amgx_size2_device
May 5, 2021
Merged

AmgxPgm cuda/hip/omp implementation and matrix/array utils#695
yhmtsai merged 16 commits into
developfrom
amgx_size2_device

Conversation

@yhmtsai

@yhmtsai yhmtsai commented Jan 27, 2021

Copy link
Copy Markdown
Member

This PR implements the amgxpgm device code with aggregation size = 2 except for dpc++.

Also, collect those utils in core/test/utils

  • array generator
  • symmetric/Hermitian/diag_dominant/hpd(spd)
  • add doc and type test

TODO:

@yhmtsai yhmtsai self-assigned this Jan 27, 2021
@ginkgo-bot ginkgo-bot added mod:all This touches all Ginkgo modules. reg:build This is related to the build system. reg:testing This is related to testing. type:matrix-format This is related to the Matrix formats type:multigrid This is related to multigrid labels Jan 27, 2021
@codecov

codecov Bot commented Jan 27, 2021

Copy link
Copy Markdown

Codecov Report

Merging #695 (8b5901b) into develop (e18a183) will increase coverage by 0.10%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop     #695      +/-   ##
===========================================
+ Coverage    94.05%   94.16%   +0.10%     
===========================================
  Files          392      399       +7     
  Lines        30647    30829     +182     
===========================================
+ Hits         28825    29029     +204     
+ Misses        1822     1800      -22     
Impacted Files Coverage Δ
core/device_hooks/common_kernels.inc.cpp 0.00% <ø> (ø)
core/test/utils.hpp 100.00% <ø> (ø)
core/test/utils/matrix_generator.hpp 100.00% <ø> (ø)
omp/test/solver/gmres_kernels.cpp 100.00% <ø> (ø)
omp/test/solver/idr_kernels.cpp 100.00% <ø> (ø)
core/multigrid/amgx_pgm.cpp 96.61% <100.00%> (+1.44%) ⬆️
core/test/utils/array_generator.hpp 100.00% <100.00%> (ø)
core/test/utils/array_generator_test.cpp 100.00% <100.00%> (ø)
core/test/utils/matrix_generator_test.cpp 100.00% <100.00%> (ø)
core/test/utils/matrix_utils.hpp 100.00% <100.00%> (ø)
... and 27 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd33473...8b5901b. Read the comment docs.

@yhmtsai yhmtsai mentioned this pull request Mar 5, 2021
9 tasks
@yhmtsai yhmtsai force-pushed the amgx_size2_device branch 6 times, most recently from 785fa8f to 3edc90d Compare March 15, 2021 07:24
@yhmtsai yhmtsai added the 1:ST:ready-for-review This PR is ready for review label Mar 15, 2021
@yhmtsai yhmtsai force-pushed the amgx_size2_device branch from 3edc90d to be869fe Compare March 17, 2021 07:23

@tcojean tcojean left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I only have a few comments.

Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
Comment on lines +82 to +83
agg_vals[i] = group;
agg_vals[neighbor] = group;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function gets me a bit confused for now. I didn't look too deep into it, but couldn't there be some concurrent access issues on these data as both agg_vals[i] and agg_vals[neighbor] could be accessed by different threads in at least two different places?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should be okay on the results aspect.
they always set the smaller index, so they should write the same result from two points.
I can do it with condition but I need to check what impact is.

@tcojean tcojean Mar 25, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends entirely on what the neighbors set look like. If it's symmetric (neighbor[i] = j and neighbor[j] = i), then there should be no issue as you say. But if you have cases where neighbor[i] = j, neighbor[j] = k and neighbor[k] = i (or anything else), then you could get different results depending on what gets executed first, I think?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case you mentioned does not work in the previous one, either.
Those points with circular strong neighbor will be assigned in the last step.
The original one: the both side of strongest connection will set the smaller index as aggregation group.
Current one: only the smaller one proceed settin the aggregation of both side.

@upsj upsj Apr 18, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think especially considering the weaker memory model for C++ on ARM processors, we should give this some thought. There is a potential RAW race condition between the write in agg_vals[neighbor] = i; and the read in agg_vals[i] == -1. This might be especially problematic if the reads and writes are torn, i.e. implemented as two distinct memory transactions, and potentially even reordered.
If any (partial) write to agg_vals[neighbor] become visible to the thread where i == neighbor, the comparison will become false. I would argue though that this cannot cause any issues, since in the writing thread, i < neighbor, so the reading thread would have i > neighbor and thus would not write to memory itself. Does that sound right to you?

This will definitely produce ThreadSanitizer warnings, though, not sure how to silence those.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for late reply.
Yes, read may be after or before the write from the smaller threads and it will not cause any issue as the reason you said.
I am not sure how ThreadSanitizer warning shows on this part.

Comment thread omp/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/test/multigrid/amgx_pgm_kernels.cpp
Comment thread omp/test/multigrid/amgx_pgm_kernels.cpp
Comment thread hip/test/multigrid/amgx_pgm_kernels.cpp
Comment thread cuda/test/multigrid/amgx_pgm_kernels.cpp
Comment thread common/multigrid/amgx_pgm_kernels.hpp.inc

@pratikvn pratikvn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Only some minor things.

Comment thread cuda/multigrid/amgx_pgm_kernels.cu Outdated
Comment thread cuda/multigrid/amgx_pgm_kernels.cu Outdated
Comment thread cuda/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread cuda/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread cuda/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread hip/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread hip/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread hip/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread hip/test/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
@yhmtsai yhmtsai force-pushed the amgx_size2_device branch from be869fe to b9f8993 Compare March 25, 2021 19:06
@yhmtsai

yhmtsai commented Mar 26, 2021

Copy link
Copy Markdown
Member Author

format!

@sonarqubecloud

Copy link
Copy Markdown

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 18 Code Smells

26.5% 26.5% Coverage
6.2% 6.2% Duplication

@upsj upsj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First part of my review, there are a few questions and suggestions.

I still need to take a closer look at the GPU implementation of the coarse matrix computation

Comment thread common/multigrid/amgx_pgm_kernels.hpp.inc Outdated
Comment thread common/multigrid/amgx_pgm_kernels.hpp.inc Outdated
Comment thread common/multigrid/amgx_pgm_kernels.hpp.inc Outdated
Comment on lines +189 to +192
// This is the undeterminstic implementation which is the same implementation of
// the previous one but agg_val == agg_const_val.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to remove the __restrict__ modifier from the two agg_val pointers and reused the same implementation?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it could be, but it will lose a little possibility such that compiler to optimize it

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also go with a macro approach to reduce duplication, but I am not sure that makes the code very readable.

Comment thread common/multigrid/amgx_pgm_kernels.hpp.inc Outdated
Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
Comment thread omp/multigrid/amgx_pgm_kernels.cpp
Comment thread omp/multigrid/amgx_pgm_kernels.cpp Outdated
Comment on lines +253 to +258
vector<map<IndexType, ValueType>> row_list(
source_nrows, map<IndexType, ValueType>{exec}, exec);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks a bit inefficient and hard to parallelize. You are doing something SpGEMM-like here, right? Do you think we could instead turn it into a two-pass algorithm (first compute row pointers, allocate, then fill the entries?) Do you have any preconditions on the data we could use? Are the column indices sorted?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be almost the reference implementation.
I do not spend too much time for optimizing them (including CUDA generation)
the column index is not sorted and maybe repeated

@yhmtsai yhmtsai force-pushed the amgx_size2_device branch 2 times, most recently from cb8ca7e to 9a0f58b Compare April 30, 2021 12:57
@yhmtsai

yhmtsai commented Apr 30, 2021

Copy link
Copy Markdown
Member Author

It can be reviewed again

@upsj upsj left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Comment thread cuda/test/multigrid/amgx_pgm_kernels.cpp
@yhmtsai yhmtsai added 1:ST:ready-to-merge This PR is ready to merge. and removed 1:ST:ready-for-review This PR is ready for review labels May 3, 2021
@yhmtsai yhmtsai force-pushed the amgx_size2_device branch 2 times, most recently from 6fc8f67 to e095dcb Compare May 4, 2021 07:56
@yhmtsai yhmtsai force-pushed the amgx_size2_device branch from e095dcb to 8b5901b Compare May 5, 2021 06:34
@yhmtsai yhmtsai merged commit f36ac48 into develop May 5, 2021
@yhmtsai yhmtsai deleted the amgx_size2_device branch May 5, 2021 11:48
@sonarqubecloud

sonarqubecloud Bot commented May 6, 2021

Copy link
Copy Markdown

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

tcojean pushed a commit that referenced this pull request Aug 20, 2021
Ginkgo release 1.4.0

The Ginkgo team is proud to announce the new Ginkgo minor release 1.4.0. This
release brings most of the Ginkgo functionality to the Intel DPC++ ecosystem
which enables Intel-GPU and CPU execution. The only Ginkgo features which have
not been ported yet are some preconditioners.

Ginkgo's mixed-precision support is greatly enhanced thanks to:
1. The new Accessor concept, which allows writing kernels featuring on-the-fly
memory compression, among other features. The accessor can be used as
header-only, see the [accessor BLAS benchmarks repository](https://github.com/ginkgo-project/accessor-BLAS/tree/develop) as a usage example.
2. All LinOps now transparently support mixed-precision execution. By default,
this is done through a temporary copy which may have a performance impact but
already allows mixed-precision research.

Native mixed-precision ELL kernels are implemented which do not see this cost.
The accessor is also leveraged in a new CB-GMRES solver which allows for
performance improvements by compressing the Krylov basis vectors. Many other
features have been added to Ginkgo, such as reordering support, a new IDR
solver, Incomplete Cholesky preconditioner, matrix assembly support (only CPU
for now), machine topology information, and more!

Supported systems and requirements:
+ For all platforms, cmake 3.13+
+ C++14 compliant compiler
+ Linux and MacOS
  + gcc: 5.3+, 6.3+, 7.3+, all versions after 8.1+
  + clang: 3.9+
  + Intel compiler: 2018+
  + Apple LLVM: 8.0+
  + CUDA module: CUDA 9.0+
  + HIP module: ROCm 3.5+
  + DPC++ module: Intel OneAPI 2021.3. Set the CXX compiler to `dpcpp`.
+ Windows
  + MinGW and Cygwin: gcc 5.3+, 6.3+, 7.3+, all versions after 8.1+
  + Microsoft Visual Studio: VS 2019
  + CUDA module: CUDA 9.0+, Microsoft Visual Studio
  + OpenMP module: MinGW or Cygwin.


Algorithm and important feature additions:
+ Add a new DPC++ Executor for SYCL execution and other base utilities
  [#648](#648), [#661](#661), [#757](#757), [#832](#832)
+ Port matrix formats, solvers and related kernels to DPC++. For some kernels,
  also make use of a shared kernel implementation for all executors (except
  Reference). [#710](#710), [#799](#799), [#779](#779), [#733](#733), [#844](#844), [#843](#843), [#789](#789), [#845](#845), [#849](#849), [#855](#855), [#856](#856)
+ Add accessors which allow multi-precision kernels, among other things.
  [#643](#643), [#708](#708)
+ Add support for mixed precision operations through apply in all LinOps. [#677](#677)
+ Add incomplete Cholesky factorizations and preconditioners as well as some
  improvements to ILU. [#672](#672), [#837](#837), [#846](#846)
+ Add an AMGX implementation and kernels on all devices but DPC++.
  [#528](#528), [#695](#695), [#860](#860)
+ Add a new mixed-precision capability solver, Compressed Basis GMRES
  (CB-GMRES). [#693](#693), [#763](#763)
+ Add the IDR(s) solver. [#620](#620)
+ Add a new fixed-size block CSR matrix format (for the Reference executor).
  [#671](#671), [#730](#730)
+ Add native mixed-precision support to the ELL format. [#717](#717), [#780](#780)
+ Add Reverse Cuthill-McKee reordering [#500](#500), [#649](#649)
+ Add matrix assembly support on CPUs. [#644](#644)
+ Extends ISAI from triangular to general and spd matrices. [#690](#690)

Other additions:
+ Add the possibility to apply real matrices to complex vectors.
  [#655](#655), [#658](#658)
+ Add functions to compute the absolute of a matrix format. [#636](#636)
+ Add symmetric permutation and improve existing permutations.
  [#684](#684), [#657](#657), [#663](#663)
+ Add a MachineTopology class with HWLOC support [#554](#554), [#697](#697)
+ Add an implicit residual norm criterion. [#702](#702), [#818](#818), [#850](#850)
+ Row-major accessor is generalized to more than 2 dimensions and a new
  "block column-major" accessor has been added. [#707](#707)
+ Add an heat equation example. [#698](#698), [#706](#706)
+ Add ccache support in CMake and CI. [#725](#725), [#739](#739)
+ Allow tuning and benchmarking variables non intrusively. [#692](#692)
+ Add triangular solver benchmark [#664](#664)
+ Add benchmarks for BLAS operations [#772](#772), [#829](#829)
+ Add support for different precisions and consistent index types in benchmarks.
  [#675](#675), [#828](#828)
+ Add a Github bot system to facilitate development and PR management.
  [#667](#667), [#674](#674), [#689](#689), [#853](#853)
+ Add Intel (DPC++) CI support and enable CI on HPC systems. [#736](#736), [#751](#751), [#781](#781)
+ Add ssh debugging for Github Actions CI. [#749](#749)
+ Add pipeline segmentation for better CI speed. [#737](#737)


Changes:
+ Add a Scalar Jacobi specialization and kernels. [#808](#808), [#834](#834), [#854](#854)
+ Add implicit residual log for solvers and benchmarks. [#714](#714)
+ Change handling of the conjugate in the dense dot product. [#755](#755)
+ Improved Dense stride handling. [#774](#774)
+ Multiple improvements to the OpenMP kernels performance, including COO,
an exclusive prefix sum, and more. [#703](#703), [#765](#765), [#740](#740)
+ Allow specialization of submatrix and other dense creation functions in solvers. [#718](#718)
+ Improved Identity constructor and treatment of rectangular matrices. [#646](#646)
+ Allow CUDA/HIP executors to select allocation mode. [#758](#758)
+ Check if executors share the same memory. [#670](#670)
+ Improve test install and smoke testing support. [#721](#721)
+ Update the JOSS paper citation and add publications in the documentation.
  [#629](#629), [#724](#724)
+ Improve the version output. [#806](#806)
+ Add some utilities for dim and span. [#821](#821)
+ Improved solver and preconditioner benchmarks. [#660](#660)
+ Improve benchmark timing and output. [#669](#669), [#791](#791), [#801](#801), [#812](#812)


Fixes:
+ Sorting fix for the Jacobi preconditioner. [#659](#659)
+ Also log the first residual norm in CGS [#735](#735)
+ Fix BiCG and HIP CSR to work with complex matrices. [#651](#651)
+ Fix Coo SpMV on strided vectors. [#807](#807)
+ Fix segfault of extract_diagonal, add short-and-fat test. [#769](#769)
+ Fix device_reset issue by moving counter/mutex to device. [#810](#810)
+ Fix `EnableLogging` superclass. [#841](#841)
+ Support ROCm 4.1.x and breaking HIP_PLATFORM changes. [#726](#726)
+ Decreased test size for a few device tests. [#742](#742)
+ Fix multiple issues with our CMake HIP and RPATH setup.
  [#712](#712), [#745](#745), [#709](#709)
+ Cleanup our CMake installation step. [#713](#713)
+ Various simplification and fixes to the Windows CMake setup. [#720](#720), [#785](#785)
+ Simplify third-party integration. [#786](#786)
+ Improve Ginkgo device arch flags management. [#696](#696)
+ Other fixes and improvements to the CMake setup.
  [#685](#685), [#792](#792), [#705](#705), [#836](#836)
+ Clarification of dense norm documentation [#784](#784)
+ Various development tools fixes and improvements [#738](#738), [#830](#830), [#840](#840)
+ Make multiple operators/constructors explicit. [#650](#650), [#761](#761)
+ Fix some issues, memory leaks and warnings found by MSVC.
  [#666](#666), [#731](#731)
+ Improved solver memory estimates and consistent iteration counts [#691](#691)
+ Various logger improvements and fixes [#728](#728), [#743](#743), [#754](#754)
+ Fix for ForwardIterator requirements in iterator_factory. [#665](#665)
+ Various benchmark fixes. [#647](#647), [#673](#673), [#722](#722)
+ Various CI fixes and improvements. [#642](#642), [#641](#641), [#795](#795), [#783](#783), [#793](#793), [#852](#852)


Related PR: #857
tcojean pushed a commit that referenced this pull request Aug 23, 2021
Release 1.4.0 to master

The Ginkgo team is proud to announce the new Ginkgo minor release 1.4.0. This
release brings most of the Ginkgo functionality to the Intel DPC++ ecosystem
which enables Intel-GPU and CPU execution. The only Ginkgo features which have
not been ported yet are some preconditioners.

Ginkgo's mixed-precision support is greatly enhanced thanks to:
1. The new Accessor concept, which allows writing kernels featuring on-the-fly
memory compression, among other features. The accessor can be used as
header-only, see the [accessor BLAS benchmarks repository](https://github.com/ginkgo-project/accessor-BLAS/tree/develop) as a usage example.
2. All LinOps now transparently support mixed-precision execution. By default,
this is done through a temporary copy which may have a performance impact but
already allows mixed-precision research.

Native mixed-precision ELL kernels are implemented which do not see this cost.
The accessor is also leveraged in a new CB-GMRES solver which allows for
performance improvements by compressing the Krylov basis vectors. Many other
features have been added to Ginkgo, such as reordering support, a new IDR
solver, Incomplete Cholesky preconditioner, matrix assembly support (only CPU
for now), machine topology information, and more!

Supported systems and requirements:
+ For all platforms, cmake 3.13+
+ C++14 compliant compiler
+ Linux and MacOS
  + gcc: 5.3+, 6.3+, 7.3+, all versions after 8.1+
  + clang: 3.9+
  + Intel compiler: 2018+
  + Apple LLVM: 8.0+
  + CUDA module: CUDA 9.0+
  + HIP module: ROCm 3.5+
  + DPC++ module: Intel OneAPI 2021.3. Set the CXX compiler to `dpcpp`.
+ Windows
  + MinGW and Cygwin: gcc 5.3+, 6.3+, 7.3+, all versions after 8.1+
  + Microsoft Visual Studio: VS 2019
  + CUDA module: CUDA 9.0+, Microsoft Visual Studio
  + OpenMP module: MinGW or Cygwin.


Algorithm and important feature additions:
+ Add a new DPC++ Executor for SYCL execution and other base utilities
  [#648](#648), [#661](#661), [#757](#757), [#832](#832)
+ Port matrix formats, solvers and related kernels to DPC++. For some kernels,
  also make use of a shared kernel implementation for all executors (except
  Reference). [#710](#710), [#799](#799), [#779](#779), [#733](#733), [#844](#844), [#843](#843), [#789](#789), [#845](#845), [#849](#849), [#855](#855), [#856](#856)
+ Add accessors which allow multi-precision kernels, among other things.
  [#643](#643), [#708](#708)
+ Add support for mixed precision operations through apply in all LinOps. [#677](#677)
+ Add incomplete Cholesky factorizations and preconditioners as well as some
  improvements to ILU. [#672](#672), [#837](#837), [#846](#846)
+ Add an AMGX implementation and kernels on all devices but DPC++.
  [#528](#528), [#695](#695), [#860](#860)
+ Add a new mixed-precision capability solver, Compressed Basis GMRES
  (CB-GMRES). [#693](#693), [#763](#763)
+ Add the IDR(s) solver. [#620](#620)
+ Add a new fixed-size block CSR matrix format (for the Reference executor).
  [#671](#671), [#730](#730)
+ Add native mixed-precision support to the ELL format. [#717](#717), [#780](#780)
+ Add Reverse Cuthill-McKee reordering [#500](#500), [#649](#649)
+ Add matrix assembly support on CPUs. [#644](#644)
+ Extends ISAI from triangular to general and spd matrices. [#690](#690)

Other additions:
+ Add the possibility to apply real matrices to complex vectors.
  [#655](#655), [#658](#658)
+ Add functions to compute the absolute of a matrix format. [#636](#636)
+ Add symmetric permutation and improve existing permutations.
  [#684](#684), [#657](#657), [#663](#663)
+ Add a MachineTopology class with HWLOC support [#554](#554), [#697](#697)
+ Add an implicit residual norm criterion. [#702](#702), [#818](#818), [#850](#850)
+ Row-major accessor is generalized to more than 2 dimensions and a new
  "block column-major" accessor has been added. [#707](#707)
+ Add an heat equation example. [#698](#698), [#706](#706)
+ Add ccache support in CMake and CI. [#725](#725), [#739](#739)
+ Allow tuning and benchmarking variables non intrusively. [#692](#692)
+ Add triangular solver benchmark [#664](#664)
+ Add benchmarks for BLAS operations [#772](#772), [#829](#829)
+ Add support for different precisions and consistent index types in benchmarks.
  [#675](#675), [#828](#828)
+ Add a Github bot system to facilitate development and PR management.
  [#667](#667), [#674](#674), [#689](#689), [#853](#853)
+ Add Intel (DPC++) CI support and enable CI on HPC systems. [#736](#736), [#751](#751), [#781](#781)
+ Add ssh debugging for Github Actions CI. [#749](#749)
+ Add pipeline segmentation for better CI speed. [#737](#737)


Changes:
+ Add a Scalar Jacobi specialization and kernels. [#808](#808), [#834](#834), [#854](#854)
+ Add implicit residual log for solvers and benchmarks. [#714](#714)
+ Change handling of the conjugate in the dense dot product. [#755](#755)
+ Improved Dense stride handling. [#774](#774)
+ Multiple improvements to the OpenMP kernels performance, including COO,
an exclusive prefix sum, and more. [#703](#703), [#765](#765), [#740](#740)
+ Allow specialization of submatrix and other dense creation functions in solvers. [#718](#718)
+ Improved Identity constructor and treatment of rectangular matrices. [#646](#646)
+ Allow CUDA/HIP executors to select allocation mode. [#758](#758)
+ Check if executors share the same memory. [#670](#670)
+ Improve test install and smoke testing support. [#721](#721)
+ Update the JOSS paper citation and add publications in the documentation.
  [#629](#629), [#724](#724)
+ Improve the version output. [#806](#806)
+ Add some utilities for dim and span. [#821](#821)
+ Improved solver and preconditioner benchmarks. [#660](#660)
+ Improve benchmark timing and output. [#669](#669), [#791](#791), [#801](#801), [#812](#812)


Fixes:
+ Sorting fix for the Jacobi preconditioner. [#659](#659)
+ Also log the first residual norm in CGS [#735](#735)
+ Fix BiCG and HIP CSR to work with complex matrices. [#651](#651)
+ Fix Coo SpMV on strided vectors. [#807](#807)
+ Fix segfault of extract_diagonal, add short-and-fat test. [#769](#769)
+ Fix device_reset issue by moving counter/mutex to device. [#810](#810)
+ Fix `EnableLogging` superclass. [#841](#841)
+ Support ROCm 4.1.x and breaking HIP_PLATFORM changes. [#726](#726)
+ Decreased test size for a few device tests. [#742](#742)
+ Fix multiple issues with our CMake HIP and RPATH setup.
  [#712](#712), [#745](#745), [#709](#709)
+ Cleanup our CMake installation step. [#713](#713)
+ Various simplification and fixes to the Windows CMake setup. [#720](#720), [#785](#785)
+ Simplify third-party integration. [#786](#786)
+ Improve Ginkgo device arch flags management. [#696](#696)
+ Other fixes and improvements to the CMake setup.
  [#685](#685), [#792](#792), [#705](#705), [#836](#836)
+ Clarification of dense norm documentation [#784](#784)
+ Various development tools fixes and improvements [#738](#738), [#830](#830), [#840](#840)
+ Make multiple operators/constructors explicit. [#650](#650), [#761](#761)
+ Fix some issues, memory leaks and warnings found by MSVC.
  [#666](#666), [#731](#731)
+ Improved solver memory estimates and consistent iteration counts [#691](#691)
+ Various logger improvements and fixes [#728](#728), [#743](#743), [#754](#754)
+ Fix for ForwardIterator requirements in iterator_factory. [#665](#665)
+ Various benchmark fixes. [#647](#647), [#673](#673), [#722](#722)
+ Various CI fixes and improvements. [#642](#642), [#641](#641), [#795](#795), [#783](#783), [#793](#793), [#852](#852)

Related PR: #866
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1:ST:ready-to-merge This PR is ready to merge. mod:all This touches all Ginkgo modules. reg:build This is related to the build system. reg:testing This is related to testing. type:matrix-format This is related to the Matrix formats type:multigrid This is related to multigrid

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants