| find . -type f \( -iname \*.cu -o -iname \*.cuh -o -iname \*.cpp -o -iname \*.hpp -o -iname \*.hxx -o -iname *.cxx \) -exec hipify-perl -inplace -experimental -print-stats {} \; |
I got Doxygen version 1.9.6 (6bc5f864d0c847a74944d6e9e4a42346e8c18b28) to build using the following instructions on Ubuntu 18.04.
sudo apt-get install graphviz bison flex
git clone https://github.com/doxygen/doxygen.git
cd doxygen
mkdir build
cd build
cmake -G "Unix Makefiles" ..
# Default installation at /usr/local/bin/doxygen
| #pragma once | |
| // Includes CUDA | |
| #include <cuda_runtime.h> | |
| #include <cooperative_groups.h> | |
| #include <utility> | |
| namespace cg = cooperative_groups; |
The following numbers are based on NVIDIA's Volta microarchitecture. To perform a similar analysis for a newer architecture, I recommend changing the numbers below based on device_query CUDA sample or wikipedia page.
CUDA Cores = SM * Cores per SM (SM = 80, Cores/SM = 64)
Maximum Clock Rate = Clock Rate (KHz) * 1e-6 (GHz)
Maximum Throughput (type == floats, doubles or half) =
CUDA Cores * Maximum Clock Rate * Type Ratio (device properties) (GFLOP/s)
Maximum Memory Bandwidth =
| #include <vector> | |
| #include <algorithm> | |
| #include <execution> | |
| #include <mutex> | |
| #include <utility> | |
| #include <ranges> | |
| struct frontier_t { | |
| // Underlying representation of frontier. | |
| std::vector<int> active_vertices; |
How crazy is it to imagine a keyword (NVCC-supported), something like __ignore__, where if you use that in front of an expression (function, variable, object, etc.), it is ignored on the device side (in __device__ and __global__). This solves the issue where complicated containers that support host and device code, and their constructors/destructors that run on host code are all just ignored on device when they are passed as a member of larger class or struct. For example;
__global__ void kernel(foo_t foo) {
auto idx = threadIdx.x;
auto ptr = foo.get_ptr();
ptr[idx] = idx;
}
We have a top-level object that the user wants to interact with, such as a pixel on the screen. But given the contents within that pixel, it may choose to color/shade it differently. If that pixel is representing a cloth, it may have a texture and color of a cloth, if it is representing metal, it may be shiny and metal-like... you get the point. To represent this object in c++, we have number of options. The most obvious one is to have a function that colors (or applies some sort of texture) to the pixel, and has the different specializations for the materials/colors within that function.
void apply_texture(pixel_t* p, texture_t t) {
if(t == texture_t::cloth) {
// apply cloth
} else if (t == texture_t::skin) {
| #include <stdio.h> | |
| #include <stdlib.h> | |
| #include <ctime> | |
| #include <random> | |
| #include <thrust/device_vector.h> | |
| #include <thrust/host_vector.h> | |
| #include <thrust/transform.h> | |
| #include <thrust/iterator/counting_iterator.h> |
For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.
After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft
CoordinateT MergePathSearch(int diagonal, int a_len, int b_len, AIteratorT a,
BIteratorT b) {
// Diagonal search range (in x coordinate space)
int x_min = max(diagonal - b_len, 0);
int x_max = min(diagonal, a_len);