文件列表:

LICENSE (1654, 2021-12-20)
Makefile (5785, 2021-12-20)
configs/ (0, 2021-12-20)
configs/backprop.json (410, 2021-12-20)
configs/counter_spin_half_vs_full_processes.json (1192, 2021-12-20)
configs/counter_spin_half_vs_full_streams.json (801, 2021-12-20)
configs/counter_spin_test_isolated.json (402, 2021-12-20)
configs/counter_spin_test_processes.json (749, 2021-12-20)
configs/counter_spin_test_streams.json (744, 2021-12-20)
configs/cu_partitioning_figure_part1.json (1042, 2021-12-20)
configs/cu_partitioning_figure_part2.json (713, 2021-12-20)
configs/cu_partitioning_figure_part3.json (946, 2021-12-20)
configs/cu_partitioning_figure_part4.json (1171, 2021-12-20)
configs/cu_partitioning_figure_part5.json (1189, 2021-12-20)
configs/cutting_ahead_figure_part1.json (774, 2021-12-20)
configs/cutting_ahead_figure_part2.json (1062, 2021-12-20)
configs/cutting_ahead_figure_part3.json (1061, 2021-12-20)
configs/cutting_ahead_timeline_figure_1.json (700, 2021-12-20)
configs/cutting_ahead_timeline_figure_2.json (1085, 2021-12-20)
configs/cutting_ahead_timeline_figure_3.json (1039, 2021-12-20)
configs/deadline_example.json (1017, 2021-12-20)
configs/dummy_streams_test.json (721, 2021-12-20)
configs/dwt2d.json (396, 2021-12-20)
configs/gaussian.json (411, 2021-12-20)
configs/huge_kernel_test.json (418, 2021-12-20)
configs/mandelbrot_1k.json (512, 2021-12-20)
configs/matrix_multiply_test.json (507, 2021-12-20)
configs/memory_copy.json (518, 2021-12-20)
configs/memory_copy_with_subdivisions.json (1076, 2021-12-20)
configs/memory_copy_without_subdivisions.json (1137, 2021-12-20)
configs/particlefilter.json (456, 2021-12-20)
configs/random_walk_test.json (439, 2021-12-20)
configs/simple.json (427, 2021-12-20)
configs/stream_actions_test.json (1242, 2021-12-20)
configs/test_dummy_lock_gpu.json (1356, 2021-12-20)
configs/timer_spin_test.json (331, 2021-12-20)
configs/two_mandelbrot.json (505, 2021-12-20)
configs/vector_add_test.json (561, 2021-12-20)
... ...

HIP Plugin Framework ==================== About ----- This project is based on the [CUDA Scheduling Examiner](https://github.com/yalue/cuda_scheduling_examiner_mirror) framework, which made it convenient to configure and examine the behavior of multiple GPU-sharing tasks on NVIDIA. The HIP plugin framework is architecturally similar, but has been overhauled to use more intuitive terminology and to remove any NVIDIA-specific code. (Which, unfortunately means that this project is unable to plot which compute units blocks are assigned to.) To cite this work, either link the repository or cite [the following paper](https://www.cs.unc.edu/~otternes/papers/rtns2021.pdf): ``` @inproceedings{otterness2021amd, title={Exploring {AMD} {GPU} Scheduling Details by Experimenting With ``Worst Practices''}, author={Otterness, Nathan and Anderson, James H.}, booktitle={International Conference on Real-Time Networks and Systems (RTNS)}, year={2021} } ``` Prerequisites ------------- Some of this project may require modified versions of AMD's HIP framework or other ROCm components (as it is intended to support my research). If any such modifications are needed, they should be included in [this repository](https://github.com/yalue/rocm_mega_repo). As of ROCm 3.7, however, this repository should not require any non-standard HIP functionality for most basic usage. Components related to setting GPU deadlines will not work unless the Linux kernel module and patches located in [this repository](https://github.com/yalue/gpu_locking_module), are present and loaded. However, this is not required if you aren't using locking; the framework will run without it as long as configs don't include the `job_deadline` setting. Basic Compilation and Usage --------------------------- Compiling this project requires HIP, and `hipcc` must be on your `PATH`. Only Linux is supported for now, and only AMD GPUs. (Compilation should also work on NVIDIA, but is not a priority and may require modifying the makefile.) To build: ```bash git clone https://github.com/yalue/hip_plugin_framework cd hip_plugin_framework make ``` To test it, run: ```bash ./bin/runner configs/simple.json ``` Configuration Files ------------------- The configuration files specify parameters passed to each plugin along with some global settings for the entire framework. See `configs/simple.json` for a minimal working example, using the Mandelbrot-set plugin. The layout of each configuration file is as follows: ``` { "name": , "max_iterations": , "max_time": , "use_processes": "gpu_device_id": , "base_result_directory": , "pin_cpus": , "do_warmup": , "sync_every_iteration": , "omit_block_times": , "plugins": [ { "filename": , "log_name": , "label:": , "thread_count": , "block_count": , "additional_info": , "max_iterations": , "max_time": , "release_time": , "initialization_delay": , "job_deadline": , "cpu_core": "compute_unit_mask": }, { } ] } ``` Additionally, configurations support the insertion of comments via the usage of "comment" keys, which will be ignored at runtime. Output File Format ------------------ Each plugin, when run, will generate a JSON log file at the location specified in the configuration. If the plugin did not complete successfully, the JSON file may be in an invalid state. Times will be recorded as floating-point numbers of seconds. The format of the log file is: ``` { "scenario_name": "", "plugin_name": "", "label": "", "max_resident_threads": , "data_size": , "release_time": , "PID": , "TID": , "times": [ {}, { "cpu_times": [ , ], "copy_in_times": [ , ], "execute_times": [ , ], "copy_out_times": [ , ], "cpu_core": }, { "kernel_name": , "block_count": , "thread_count": , "shared_memory": , "kernel_launch_times": [, , ], "block_times": [, , ..., ] }, ... ] } ``` Notice that the first entry in the "times" array will be blank and should be ignored. The times array will contain two types of objects: one will contain CPU times and one type will apply to kernel times. An object containing CPU times will contain a `"cpu_times"` key. A single CPU times object will encompass all kernel times following it, up until another CPU times object. Creating New Plugins -------------------- Each plugin must be contained in a shared library and abide by the interface specified in `src/plugin_interface.h`. In particular, the library must export a `RegisterPlugin` function, which provides the addresses of further functions to the framework. Plugins should preferably never use global state and instead use the `user_data` pointer returned by the initialize function to track all state. The reason for this is that we want to be able to run multiple instances of a single plugin at a time--global variables prevent instances of a single plugin from being independent. Similarly to global variables, plugins should use a user-created HIP stream in order to avoid unnecessarily blocking each other by `hipDeviceSynchronize` (or similar) calls. The most important piece of information that each plugin provides is the `TimingInformation` struct, which it must fill in during its `copy_out` function. This struct will contain a list of `KernelTimes` structs, one for each kernel invocation called during `execute`. Each `KernelTimes` struct will contain the kernel start and end times and, if possible, individual block start and end times (we recognize this may be quite obnoxious to add to some plugins, so `block_times` are treated as quite desirable, but still optional). The plugin is responsible for ensuring that the buffers provided in the `TimingInformation` struct remain valid at least until another plugin function is called. They will not be freed by the caller. In general, the comments in `plugin_interface.h` provide an explanation for the actions that every plugin-provided function is expected to carry out. The `src/mandelbrot.cpp` file contains a well-commented example of a working plugin implementation. In addition to `plugin_interface.h`, `plugin_utilities.h` and `plugin_hip_utilities.h` define a library of utility functions that may be used by plugins. Plugins are invoked by the framework as follows: 1. The shared library file is loaded using the `dlopen()` function, and the `RegisterPlugin` function is located using `dlysym()`. 2. Depending on the configuration, either a new process or new thread will be created for each plugin. 3. In its own thread or process, the plugin's `initialize` function will be called, in which the plugin should allocate and initialize all of the local state necessary for one instance of itself. 4. When the plugin begins running, a single "iteration" will consist of the plugin's `copy_in`, `execute`, and `copy_out` functions being called, in that order. 5. When enough time has elapsed or the maximum number of iterations has been reached, the plugin's `cleanup` function will be called, to allow for the plugin to clean up and free its local state. 6. If any of the plugin's functions, apart from `initialize` return an error, the framework will still call the plugin's `cleanup` function, and then cease calling further functions from the plugin. Coding Style ------------ Even though HIP supports C++, contributions to this project should use the C programming language when possible. C or HIP source code should adhere to the parts of the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) that apply to the C language. Scripts should remain in the `scripts/` directory and should be written in python when possible. For now, there is no explicit style guide for python scripts apart from trying to maintain a consistent style within each file. Rodinia Plugins --------------- This project contains several plugins that have been ported from the [Rodinia benchmark suite](http://lava.cs.virginia.edu/Rodinia/download_links.htm). The code for these plugins are located in the `src/third_party/rodinia_plugins` directory. The four plugins, `backprop`, `dwt2d`, `gaussian`, and `particlefilter` have been modified to clean up code, remove global variables, and to adhere to the plugin interface required by the project. Compile these plugins by running `make rodinia_plugins` in the main project directory. Some sample configs exist for testing these plugins in `configs/`. For example, running `./bin/runner configs/particlefilter.json` launches a single instance of the `particlefilter` plugin.

评论：[我要评论] [举报此文件]

收藏者：