Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: ROCm/rocFFT
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: rocm-3.1
Choose a base ref
...
head repository: ROCm/rocFFT
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: develop
Choose a head ref
Loading
Showing 448 changed files with 110,859 additions and 38,066 deletions.
44 changes: 44 additions & 0 deletions .azuredevops/rocm-ci.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
resources:
repositories:
- repository: pipelines_repo
type: github
endpoint: ROCm
name: ROCm/ROCm

variables:
- group: common
- template: /.azuredevops/variables-global.yml@pipelines_repo

trigger:
batch: true
branches:
include:
- develop
- mainline
paths:
exclude:
- .githooks
- .github
- .jenkins
- docs
- '.*.y*ml'
- '*.md'

pr:
autoCancel: true
branches:
include:
- develop
- mainline
paths:
exclude:
- .githooks
- .github
- .jenkins
- docs
- '.*.y*ml'
- '*.md'
drafts: false

jobs:
- template: ${{ variables.CI_COMPONENT_PATH }}/rocFFT.yml@pipelines_repo
2 changes: 1 addition & 1 deletion .githooks/pre-commit
Original file line number Diff line number Diff line change
@@ -4,7 +4,7 @@
# are installed, and if so, uses the installed version to format
# the staged changes.

base=/opt/rocm/hcc/bin/clang-format
base=/opt/rocm/llvm/bin/clang-format
format=""

# Redirect output to stderr.
8 changes: 8 additions & 0 deletions .github/CODEOWNERS
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
* @af-ayala @eng-flavio-teixeira @evetsso @feizheng10 @malcolmroberts
# Documentation files
docs/ @ROCm/rocm-documentation
*.md @ROCm/rocm-documentation
*.rst @ROCm/rocm-documentation
.readthedocs.yaml @ROCm/rocm-documentation
# Header directory for Doxygen documentation
library/include/ @ROCm/rocm-documentation @af-ayala @eng-flavio-teixeira @evetsso @feizheng10 @malcolmroberts
178 changes: 126 additions & 52 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,53 +1,127 @@
<head>
<meta charset="UTF-8">
<meta name="description" content="Contributing to rocFFT">
<meta name="keywords" content="ROCm, contributing, rocFFT">
</head>

## Contribution License Agreement
1. The code I am contributing is mine, and I have the right to license it.

2. By submitting a pull request for this project I am granting you a license to distribute said code under the MIT License for the project.

## How to contribute

Our code contriubtion guidelines closely follows the model of [GitHub pull-requests](https://help.github.com/articles/using-pull-requests/). This repository follows the [git flow](http://nvie.com/posts/a-successful-git-branching-model/) workflow, which dictates a /master branch where releases are cut, and a /develop branch which serves as an integration branch for new code.
* A [git extention](https://github.com/nvie/gitflow) has been developed to ease the use of the 'git flow' methodology, but requires manual installation by the user. Refer to the projects wiki

## Pull-request guidelines
* target the **develop** branch for integration
* ensure code builds successfully.
* do not break existing test cases
* new functionality will only be merged with new unit tests
* new unit tests should integrate within the existing [googletest framework](https://github.com/google/googletest/blob/master/googletest/docs/Primer.md)
* tests must have good code coverage
* code must also have benchmark tests, and performance must approach the compute bound limit or memory bound limit.

## StyleGuide
This project follows the [CPP Core guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md), with few modifications or additions noted below. All pull-requests should in good faith attempt to follow the guidelines stated therein, but we recognize that the content is lengthy. Below we list our primary concerns when reviewing pull-requests.

### Interface
- All public APIs are C89 compatible; all other library code should use c++14
- Our minimum supported compiler is clang 3.6
- Avoid CamelCase
- This rule applies specifically to publicly visible APIs, but is also encouraged (not mandated) for internal code

### Philosophy
- [P.2](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rp-Cplusplus): Write in ISO Standard C++ (especially to support windows, linux and macos plaforms )
- [P.5](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rp-compile-time): Prefer compile-time checking to run-time checking

### Implementation
- [SF.1](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix): Use a .cpp suffix for code files and .h for interface files if your project doesn't already follow another convention
- We modify this rule:
- .h: C header files
- .hpp: C++ header files
- [SF.5](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-consistency): A .cpp file must include the .h file(s) that defines its interface
- [SF.7](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using-directive): Don't put a using-directive in a header file
- [SF.8](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-guards): Use #include guards for all .h files
- [SF.21](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-unnamed): Don't use an unnamed (anonymous) namespace in a header
- [SL.10](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rsl-arrays): Prefer using STL array or vector instead of a C array
- [C.9](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-private): minimize exposure of members
- [F.3](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-single): Keep functions short and simple
- [F.21](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-out-multi): To return multiple 'out' values, prefer returning a tuple
- [R.1](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rr-raii): Manage resources automatically using RAII (this includes unique_ptr & shared_ptr)
- [ES.11](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-auto): use auto to avoid redundant repetition of type names
- [ES.20](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-always): Always initialize an object
- [ES.23](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-list): Prefer the {} initializer syntax
- [ES.49](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-casts-named): If you must use a cast, use a named cast
- [CP.1](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-concurrency): Assume that your code will run as part of a multi-threaded program
- [I.2](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-global): Avoid global variables
# Contributing to rocFFT #

We welcome contributions to rocFFT. Please follow these details to help ensure your contributions will be successfully accepted.

## Issue Discussion ##

Please use the GitHub Issues tab to notify us of issues.

* Use your best judgment for issue creation. If your issue is already listed, upvote the issue and
comment or post to provide additional details, such as how you reproduced this issue.
* If you're not sure if your issue is the same, err on the side of caution and file your issue.
You can add a comment to include the issue number (and link) for the similar issue. If we evaluate
your issue as being the same as the existing issue, we'll close the duplicate.
* If your issue doesn't exist, use the issue template to file a new issue.
* When filing an issue, be sure to provide as much information as possible, including script output so
we can collect information about your configuration. This helps reduce the time required to
reproduce your issue.
* Check your issue regularly, as we may require additional information to successfully reproduce the
issue.
* You may also open an issue to ask questions to the maintainers about whether a proposed change
meets the acceptance criteria, or to discuss an idea pertaining to the library.

## Acceptance Criteria ##

When a contribution is submitted via a pull request, a number of automated checks are run in order to verify compilation correctness and prevent performance regressions.

These checks include:

* Building and testing the change on various OS platforms (Ubuntu, RHEL, etc.)
* Running on different GPU architectures (MI-series, Radeon series cards, etc.)
* Running benchmarks to check for performance degradation

In order for a submission to be accepted:
* It must pass all of the automated checks
* It must undergo a code review

Users can visualize our continuous integration infrastructure in: `rocFFT/.jenkins`.

The GitHub "Issues" tab may also be used to discuss ideas surrounding particular features or changes before raising pull requests.

## Code Structure ##

In a broad view, rocFFT library is structured as follows:

├── docs/: contains rocFFT documentation
├── library/: contains main source code and headers
├── clients/:
│   ├── bench/ : contains benchmarking code
│   ├── samples/ : contains examples
│   ├── tests/ : contains our test infrastructure
├── shared/: contains important global headers and those for linking to other applications

## Coding Style ##

* All public APIs are C89 compatible; all other library code should use c++17.
* Our minimum supported compiler is clang 3.6.
* Avoid CamelCase: rule applies specifically to publicly visible APIs, but is encouraged (not mandated) for internal code.

* C and C++ code should be formatted using `clang-format`. You can use the clang-format version available in `rocFFT/.clang-format`.

To format a C/C++ file, use:

```
clang-format -style=file -i <path-to-source-file>
```
* Python code should use:
```
yapf --style pep8
```
## Pull Request Guidelines ##
Our code contribution guidelines closely follow the model of [GitHub pull-requests](https://help.github.com/articles/using-pull-requests/).
This repository follows the [git flow](http://nvie.com/posts/a-successful-git-branching-model/) workflow, which dictates a /master branch where releases are cut, and a /develop branch which serves as an integration branch for new code.
Note that a [git extension](https://github.com/nvie/gitflow) has been developed to ease the use of the 'git flow' methodology, but requires manual installation by the user.
The following guidelines apply:
* When you create a pull request, you should target the default branch. Our current default branch is the **develop** branch.
* Note that releases are cut to release/rocm-rel-x.y, where x and y refer to the release major and minor numbers.
* Ensure code builds successfully.
* Do not break existing test cases
* Code must also have benchmark tests, and performance must approach the compute bound limit or memory bound limit.
### Deliverables ###
New changes should include test coverage. Our testing infrastructure is located in `clients/tests/`, and can be used as a reference.
The following guidelines apply:
* New functionality will only be merged with new unit tests.
* New unit tests should integrate within the existing [googletest framework](https://github.com/google/googletest/blob/master/googletest/docs/Primer.md).
* Tests must have good code coverage.
### Process ###
All pull requests must pass through the checks and the code review described in the [Acceptance Criteria](#acceptance-criteria) section before they can be merged.
Once a contribution is ready to be submitted, consider the following:
* Before you create a PR, ensure that all files have been gone through the clang formatting: clang-format -i <changed_file>
* While creating a PR, you can take a look at a `diff` of the changes you made using the PR's "Files" tab, and verify that no unintentional changes are being submitted.
* Checks may take some time to complete. You can view their progress in the table near the bottom of the pull request page. You may also be able to use the links in the table to view logs associated with a check if it fails.
* During code reviews, another developer will take a look through your proposed change. If any modifications are requested (or further discussion about anything is needed), they may leave a comment. You can follow up and respond to the comment, and/or create comments of your own if you have questions or ideas.
* When a modification request has been completed, the conversation thread about it will be marked as resolved.
* To update the code in your PR (eg. in response to a code review discussion), you can simply push another commit to the branch used in your pull request.
* Once your contribution is approved, we will use the *squash merge* option from GitHub to integrate it to the corresponding branch.
## Code License ##
All code contributed to this project will be licensed under the license identified in the [LICENSE.md](https://github.com/ROCm/rocFFT/blob/develop/LICENSE.md). Your contribution will be accepted under the same license.
18 changes: 18 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
- package-ecosystem: "pip" # See documentation for possible values
directory: "/docs/sphinx" # Location of package manifests
open-pull-requests-limit: 10
schedule:
interval: "daily"
labels:
- "documentation"
- "dependencies"
- "ci:docs-only"
reviewers:
- "samjwu"
5 changes: 4 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -36,4 +36,7 @@ tags
.vscode

# install.sh build dir
build/
build/

# python bytecode
__pycache__
50 changes: 0 additions & 50 deletions .jenkins/Common.groovy

This file was deleted.

47 changes: 0 additions & 47 deletions .jenkins/HipClang.groovy

This file was deleted.

Loading