Add expected behavior to unified memory #3617
Conversation
matyas-streamhpc
requested review from
gandryey,
mangupta and
rakesroy
as code owners
neon60
force-pushed
the
update-unified-memory
branch
from
da1233f
to
267b2f2
Compare
neon60
force-pushed
the
docs/develop
branch
from
98f9599
to
73814d1
Compare
neon60
force-pushed
the
update-unified-memory
branch
3 times, most recently
from
7e27ba9
to
84f9097
Compare
neon60
force-pushed
the
docs/develop
branch
from
0049c2b
to
e7486be
Compare
neon60
force-pushed
the
update-unified-memory
branch
4 times, most recently
from
934e4d3
to
4baf272
Compare
neon60
force-pushed
the
update-unified-memory
branch
3 times, most recently
from
546b8d9
to
6244fc2
Compare
MKKnorr
force-pushed
the
update-unified-memory
branch
from
f4ab47d
to
74ebf79
Compare
docs/how-to/hip_runtime_api/memory_management/unified_memory.rst
Outdated
Show resolved
Hide resolved
neon60
force-pushed
the
hip_runtime_api_how-to
branch
from
38d2787
to
8d5b771
Compare
neon60
force-pushed
the
update-unified-memory
branch
from
6879e02
to
ab44e41
Compare
docs/how-to/hip_runtime_api.rst
Outdated
| ******************************************************************************** | ||
|
|
||
| The HIP runtime API provides C and C++ functionalities to manage event, stream, | ||
| and memory on GPUs. On AMD ROCm software, the HIP runtime uses :doc:`Common |
There was a problem hiding this comment.
| and memory on GPUs. On AMD ROCm software, the HIP runtime uses :doc:`Common | |
| and memory on GPUs. On AMD ROCm software, the HIP runtime uses :doc:`Compute |
There was a problem hiding this comment.
Apparently CLR is supposed to be Compute Language Runtime
| The runtime offers functions for allocating, freeing, and copying device memory, | ||
| along with transferring data between host and device memory. | ||
|
|
||
| Here are the various memory management techniques: |
There was a problem hiding this comment.
It seems like these techniques could use a brief description?
| .. figure:: ../../../data/how-to/hip_runtime_api/memory_management/pageable_pinned.svg | ||
|
|
||
| The pageable and pinned memory allow you to exercise direct control over | ||
| memory operations, which is known as explicit memory management. When using the |
There was a problem hiding this comment.
In memory_management.rst we list four memory management techniques, none of which is "explicit memory management". Is it possible to relate this explicit memory management to one of the four techniques? Or should it be listed as one of the techniques?
| // Run the kernel | ||
| // ... | ||
|
|
||
| HIP_CHECK(hipMemcpy(device_input, host_input, element_number * sizeof(int), hipMemcpyHostToDevice)); |
There was a problem hiding this comment.
This doesn't seem right to me. We have device_output and host_output, shouldn't those come into play here?
| Pinned memory | ||
| ================================================================================ | ||
|
|
||
| Pinned memory or page-locked memory is stored in pages that are locked in specific sectors in RAM and can't be migrated. The pointer can be used on both |
There was a problem hiding this comment.
Seems like we should note that pinned memory is allocated by hipMalloc() and hipHostMalloc().
| // Run the kernel | ||
| // ... | ||
|
|
||
| HIP_CHECK(hipMemcpy(device_input, host_input, element_number * sizeof(int), hipMemcpyHostToDevice)); |
| as HBM2e. Device memory can be allocated as global memory, constant, texture or | ||
| surface memory. | ||
|
|
||
| Global memory |
There was a problem hiding this comment.
I suggest making this a bulleted list rather than four separate subheads.
docs/how-to/hip_runtime_api/memory_management/device_memory.rst
Outdated
Show resolved
Hide resolved
| :sup:`1` The :cpp:func:`hipHostMalloc` memory allocation coherence mode can be | ||
| affected by the ``HIP_HOST_COHERENT`` environment variable, if the | ||
| ``hipHostMallocCoherent``, ``hipHostMallocNonCoherent``, and | ||
| ``hipHostMallocMapped`` are unset. If neither these flags nor the |
There was a problem hiding this comment.
Here the footnote to the table references hipHostMallocMapped flag, but the table above does not show this flag. This also is mentioned in the following note.
docs/how-to/hip_runtime_api/memory_management/virtual_memory.rst
Outdated
Show resolved
Hide resolved
| functions. To unmap the memory, use :cpp:func:`hipMemUnmap`. To release the | ||
| virtual address range, use :cpp:func:`hipMemAddressFree`. Finally, to release | ||
| the physical memory, use :cpp:func:`hipMemRelease`. A side effect of these | ||
| functions is the lack of synchronization when memory is released. If you call |
There was a problem hiding this comment.
If you call :cpp:func:hipFree when you have multiple streams running in parallel, it
synchronizes the device. This causes worse resource usage and performance.
This seems like it could be an important note?
There was a problem hiding this comment.
On line 24: - Learning curve: Requires additional effort to understand and utilize SOMA effectively.
neon60
force-pushed
the
update-unified-memory
branch
from
78c8a5a
to
aa3584c
Compare
neon60
force-pushed
the
update-unified-memory
branch
from
aa3584c
to
7c6949e
Compare
neon60
force-pushed
the
hip_runtime_api_how-to
branch
2 times, most recently
from
eb41cb1
to
7cb026c
Compare
MKKnorr
force-pushed
the
update-unified-memory
branch
2 times, most recently
from
0c4abec
to
07a7fdc
Compare
MKKnorr
force-pushed
the
update-unified-memory
branch
from
07a7fdc
to
af9064b
Compare
neon60
force-pushed
the
hip_runtime_api_how-to
branch
from
0c52420
to
31fa125
Compare
MKKnorr
force-pushed
the
update-unified-memory
branch
from
af9064b
to
3a46d61
Compare
MKKnorr
force-pushed
the
update-unified-memory
branch
from
3a46d61
to
890f0a5
Compare
No description provided.