Repository navigation
Improve roofline documentation - #180
cfallows-amd wants to merge 4 commits into
Conversation
Add photos, remove dupes, add references to other pages referencing roofline. Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
| @@ -0,0 +1,197 @@ | |||
| .. meta:: | |||
There was a problem hiding this comment.
Please update sphinx/_toc* files for this new .rst file
|
|
||
| * :doc:`LDS </conceptual/local-data-share.html>`: local data share, or shared memory, is fast on-CU scratchpad that can be managed by SW to effectively share data and coordinate between wavefronts in a workgroup. | ||
|
|
||
| * :doc:`L1 cache </conceptual/vector-l1-cache.html>`: the vL1d, or vector L1 data cache, is local to each CU on an accelerator and handles vector memory operations issued by a wavefront. |
There was a problem hiding this comment.
Is vL1D cache shared among CUs in a shader engine?
There was a problem hiding this comment.
L1 data cache is private to CU
vedithal-amd
left a comment
vedithal-amd
left a comment
There was a problem hiding this comment.
LGTM, thank you so much for working on this!
@prbasyal-amd @peterjunpark seems like documentation is not building using sphinx command mentioned in https://rocm.docs.amd.com/en/latest/contribute/contributing.html#editing-and-adding-to-the-documentation, could you please help?
|
|
||
| * :ref:`Peak MFMA <desc-mfma>`: matrix fused multiply add instructions where entries of the input and output matrices are distributed over the lanes of the wavefront’s vector registers. | ||
|
|
||
| Let’s start with the red kernel point- it is a memory-intensive workload, and because it sits just under peak memory bandwidth line, we are restricted in performance by how fast we can move data. Seeing a kernel point here would first suggest to us that we are bottlenecked by a specific memory stage and might want to reevaluate memory access implementation. Another obervation would be that we should optimize our code to do more operations on loaded data before needing more- this is the arithmetic intensity measurement- how much work we can do on the same data. Some examples of this would be to change precision (for example single precision over double precision for space and speed), use the vector units more efficiently, multithreading, use optimized kernels or other rocm software. Applications that are throughput bound by GEMM computation can achieve additional speedups by utilizing Matrix Cores. Generalized Matrix Multiplication (GEMM) computations are hardware-accelerated through Matrix Core Processing Units to achieve speedup, compared to SIMD vector units. |
There was a problem hiding this comment.
We should also ask @feizheng10 , @benrichard-amd and @skyreflectedinmirrors for fact checking technical points, just to be safe :)
| * Visualized memory chart requires the width of the terminal output to be greater than or equal to 234 to display the whole chart properly. | ||
| * Visualized Roofline chart is adapted to the initial terminal size only. If it is not clear, you may need to adjust the terminal size and regenerate it to check the display effect. | ||
|
|
||
| All CLI, TUI, and GUI modes in analysis stage can use the same roofline analyze options. CLI and TUI display roofline plot using plotext, and GUI uses plotly (same method as our roofline PDF plot outputs). |
There was a problem hiding this comment.
Does TUI display roofline?
There was a problem hiding this comment.
Actually, roofline is currently disabled for TUI
* SWDEV-527299 - Support HIP_POINTER_ATTRIBUTE_CONTEXT As HIP enables UVA by default, it seems we can simply expose the context to support this feature.
|
|
||
| * The performance counter collection which profiles the user’s workload itself. For roof-only case, we limit the counters to only those necessary for roofline analysis purposes. This data is used to plot the kernel points on the roofline graph. | ||
|
|
||
| * The roofline micro-benchmarking which profiles the hardware capabilities of the system. This part executes the roofline binary, comprised of benchmarks that compute the theoretical peak of the hardware per data type. This phase is dependent on both the hardware architecture and the customer’s hardware settings, such as clock speed for example. This data is used to plot the ‘peaks’, or lines on the graph. |
There was a problem hiding this comment.
"theoretical peak", I'd suggest to say " attainable peak "
| --------------------- | ||
| Profiling Options | ||
| --------------------- | ||
| In profiling mode, we collect the roofline-related performance counters for a user's workload and roofline benchmarks for the system's theoretical throughput. Roofline analysis occurs on any profile mode run, provided ``--no-roof`` option is not included. You don't need to include any additional roofline-specific options for roofline analysis. If you want to focus only on roofline-specific performance data and reduce the time it takes to profile, you can use the ``--roof-only`` option. This option limits the profiling to just the roofline performance counters. |
There was a problem hiding this comment.
The same here. I'd suggest to say "empirical attainable peak" but not theoretical.
Generally, when people mention theoretical peak, they are talking about the one against the peak spec.
Maybe there will be a day we actually add the theoretical one, or whenever the unified roofline yaml done, we could mention in the doc: users could customize by themselves.
github-actions
Bot
added
the
documentation
|
Additions from #325 have been updated in roofline docs. Namely per-kernel roofline analysis being displayed alongside detailed, structured table outputs (with example command and example new output for block section 4) along with measured empirical peak values for comparison. |
|
@cfallows-amd can we hold off on merging this until roofline metrics PR is merged https://github.com/ROCm/rocm-systems/pull/325/files, and then we can make any roofline documentation changes here while keeping roofline metrics into consideration. |
|
@vedithal-amd yes forgot to note here, James and I are working on other roofline-related PRs that have higher priority and would clash with these changes. This doc PR is on hold until those changes have made it into develop. Thanks |
* SWDEV-527299 - Support HIP_POINTER_ATTRIBUTE_CONTEXT As HIP enables UVA by default, it seems we can simply expose the context to support this feature. [ROCm/clr commit: b434fbe]
|
@cfallows-amd I think the documentation might need a lot of updating due to multiple roofline changes merged since this PR was created. Feel free to either update this PR or close this one and create a new PR, thanks! |
|
Closing old documentation PR as there were significant merging conflicts to resolve unrelated to docs- this is due to time between PR open and now. New PR will be started. |
- Initialize the entire pSync buffer with the default synchronization value
- Initialize the entire pSync buffer with the default synchronization value [ROCm/rocshmem commit: 6dba253]
[ROCm/rocjpeg commit: 6ad4ac6]
The examples can now be installed to `share/doc/examples/*` by setting `AIS_INSTALL_EXAMPLES` (formerly `AIS_BUILD_EXAMPLES`) to ON Part of AIHIPFILE-120
The examples can now be installed to `share/doc/examples/*` by setting `AIS_INSTALL_EXAMPLES` (formerly `AIS_BUILD_EXAMPLES`) to ON Part of AIHIPFILE-120 [ROCm/hipFile commit: 84375b7]
Add standalone roofline documentation page
No code changes.