This is the main repository for the source code for HIPRT.
git clone https://github.com/GPUOpen-LibrariesAndSDKs/HIPRT
cd HIPRT
git submodule update --init --recursive
On Windows:
4. .\tools\premake5\win\premake5.exe vs2022
5. Open build\hiprt.sln with Visual Studio 2022.
On Linux:
4. ./tools/premake5/linux64/premake5 gmake
5. make -C build -j config=release_x64
Add the option --bitcode
to enable precompiled bitcode.
- After premake, go to
scripts/bitcodes
, then runpython compile.py
which compiles kernels to bitcode and fatbinary. - Or pass
--precompile
to premake. it executes thecompile.py
during premake. Note that you cannot do it in git bash on windows (because of hipcc...)
There are three types of tests.
- HiprtTests - tests covering all basic features.
- ObjTestCases - tests with loading meshes and testing advanced features like shadow/ AO.
- PerformanceTestCases - tests with complex mesh to test performance features.
Example: ..\dist\bin\Release\unittest64.exe --width=512 --height=512 --referencePath=.\references\ --gtest_filter=hiprt*:Obj*"
- Clone
hipSdk
repo to the root directory. - Go to
scripts/bitcodes
, runpython compile.py
which useshipcc
from thehipSdk
directory. (todo. make it more general, maybe search forhipcc
from path, if it's not found, use the directory above or something like this)- Note use python version 3.*+.
- Git bash shell is not supported for compile.py.
- Resolve compiler warnings.
- Use lower camel case for variable names (e.g.,
nodeCount
) and upper camel case for constants (e.g.,LogSize
). - Separate functions by one line.
- Use prefix
m_
for non-static member variables. - Do not use static local variables.
- Do not use
void
for functions without arguments (leave it blank). - Do not use blocks without any reason.
- Use references instead of pointers if possible.
- Use bit-fields instead of explicit bit masking if possible.
- Use
nullptr
instead ofNULL
or zero. - Use C++-style casts (e.g.,
static_cast
) instead of C-style cast. - Add
const
for references and pointers if they are not being changed. - Add
constexpr
for variables and functions if they can be constant in compile time (do not use#define
if possible). - Use
if constsexpr
instead of#ifdef
if possible. - Throw
std::runtime_error
with an appropriate message in case of failure in the core and catch it inhiprt.cpp
.
- Use
std::string
instead of C strings (i.e.,char*
) and avoid C string functions as much as possible. - Use
std::cout
andstd::cerr
instead ofprintf
. - Do not assign
char8_t
(orstd::u8string
) tochar
(orstd::string
). They will not be compatible in C++20.
- Use
std::ifstream
andstd::ofstream
instead ofFILE
. - Use
std::filesystem::path
for files and paths instead ofstd::string
.
- Use the in-class initializer instead of the default constructor.
- Use the keyword
override
instead ofvirtual
(or nothing) when overriding a virtual function from the base class.- Reason: The
override
keyword can help prevent bugs by producing compilation errors when the intended override is not actually implemented as an override. For example, when the function type is not exactly identical to the base class function. This can be caused by mistakes or if the virtual functions in the base class are changed due to refactor.
- Reason: The
- Use
std::optional
instead of pointers for optional parameters.- Reason:
std::optional
guarantees that no auxiliary memory allocation is needed. Meaning, it does not involve dynamic memory allocation & deallocation on the heap, which results in better performance and less memory overhead.
- Reason:
- A base class destructor should be either public and virtual, or protected and non-virtual
- Reason: This is to prevent undefined behavior. If the destructor is public, then the calling code can attempt to destroy a derived class object/instance through a base class pointer, and the result is undefined if the base class’s destructor is non-virtual.
- Implement the customized {copy/move} {constructor/assignment operator} if an user-defined destructor of a class is needed, or remove them using
= delete
- Reason: Rule of five
- When we update the master branch, we need to update the version number of hiprt in
version.txt
. - If there is a change in the API, you need to update minor version.
- If the major and minor versions matches, the binaries are compatible.
- Each commit in the master should have a unique patch version.