Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue]: vram_usage returned by rsmi_compute_process_info_get is 0 #165

Open
eugen-ajechiloae-clearml opened this issue Apr 16, 2024 · 5 comments

Comments

@eugen-ajechiloae-clearml

Problem Description

Hi! It looks like the vram_usage returned by rsmi_compute_process_info_get is always 0. Snippet to reproduce:

import pyrsmi as R
R.smi_initialize()
from ctypes import *
num_procs = c_uint32()
ret = R.rocm_lib.rsmi_compute_process_info_get(None, byref(num_procs))
buff_sz = num_procs.value + 10
proc_info = (R.rsmi_process_info_t * buff_sz)()
ret2 = R.rocm_lib.rsmi_compute_process_info_get(byref(proc_info), byref(num_procs))
print([(proc_info[i].vram_usage, proc_info[i].process_id, proc_info[i].pasid, proc_info[i].sdma_usage, proc_info[i].cu_occupancy) for i in range(num_procs.value)] if R.rsmi_ret_ok(ret2) else [])

Querying the VRAM of the processes one by one seems to work tho:

 num_procs = c_uint32()
ret = R.rocm_lib.rsmi_compute_process_info_get(None, byref(num_procs))
if R.rsmi_ret_ok(ret):
    buff_sz = num_procs.value + 10
    proc_info = (R.rsmi_process_info_t * buff_sz)()
    ret = R.rocm_lib.rsmi_compute_process_info_get(byref(proc_info), byref(num_procs))
    proc_info_list = (
        [proc_info[i] for i in range(num_procs.value)]
        if R.rsmi_ret_ok(ret)
        else []
    )
    result_proc_info_list = []
    # query VRAM usage explicitly, as rsmi_compute_process_info_get
    # doesn't actually return VRAM usage
    for proc_info in proc_info_list:
        vram_query_proc_info = R.rsmi_process_info_t()
        ret = R.rocm_lib.rsmi_compute_process_info_by_pid_get(
            int(proc_info.process_id), byref(vram_query_proc_info)
        )
        if R.rsmi_ret_ok(ret):
            proc_info.vram_usage = vram_query_proc_info.vram_usage
            result_proc_info_list.append(proc_info)
    return result_proc_info_list
return []

Note that I am running this inside a Docker container on aac.amd.
The driver info is:

======================= ROCm System Management Interface =======================
========================= Version of System Component ==========================
Driver version: 6.2.4

Operating System

Ubuntu 20.04.6 LTS (Focal Fossa)

CPU

AMD EPYC 7643 48-Core Processor

GPU

AMD Instinct MI250X

ROCm Version

ROCm 6.0.0

ROCm Component

No response

Steps to Reproduce

No response

(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support

\ROCk module is loaded

HSA System Attributes

Runtime Version: 1.1
System Timestamp Freq.: 1000.000000MHz
Sig. Max Wait Duration: 18446744073709551615 (0xFFFFFFFFFFFFFFFF) (timestamp count)
Machine Model: LARGE
System Endianness: LITTLE

==========
HSA Agents


Agent 1


Name: AMD EPYC 7643 48-Core Processor
Uuid: CPU-XX
Marketing Name: AMD EPYC 7643 48-Core Processor
Vendor Name: CPU
Feature: None specified
Profile: FULL_PROFILE
Float Round Mode: NEAR
Max Queue Number: 0(0x0)
Queue Min Size: 0(0x0)
Queue Max Size: 0(0x0)
Queue Type: MULTI
Node: 0
Device Type: CPU
Cache Info:
L1: 32768(0x8000) KB
Chip ID: 0(0x0)
ASIC Revision: 0(0x0)
Cacheline Size: 64(0x40)
Max Clock Freq. (MHz): 2300
BDFID: 0
Internal Node ID: 0
Compute Unit: 48
SIMDs per CU: 0
Shader Engines: 0
Shader Arrs. per Eng.: 0
WatchPts on Addr. Ranges:1
Features: None
Pool Info:
Pool 1
Segment: GLOBAL; FLAGS: FINE GRAINED
Size: 1044354092(0x3e3f942c) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
Pool 2
Segment: GLOBAL; FLAGS: KERNARG, FINE GRAINED
Size: 1044354092(0x3e3f942c) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
Pool 3
Segment: GLOBAL; FLAGS: COARSE GRAINED
Size: 1044354092(0x3e3f942c) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
ISA Info:


Agent 2


Name: AMD EPYC 7643 48-Core Processor
Uuid: CPU-XX
Marketing Name: AMD EPYC 7643 48-Core Processor
Vendor Name: CPU
Feature: None specified
Profile: FULL_PROFILE
Float Round Mode: NEAR
Max Queue Number: 0(0x0)
Queue Min Size: 0(0x0)
Queue Max Size: 0(0x0)
Queue Type: MULTI
Node: 1
Device Type: CPU
Cache Info:
L1: 32768(0x8000) KB
Chip ID: 0(0x0)
ASIC Revision: 0(0x0)
Cacheline Size: 64(0x40)
Max Clock Freq. (MHz): 2300
BDFID: 0
Internal Node ID: 1
Compute Unit: 48
SIMDs per CU: 0
Shader Engines: 0
Shader Arrs. per Eng.: 0
WatchPts on Addr. Ranges:1
Features: None
Pool Info:
Pool 1
Segment: GLOBAL; FLAGS: FINE GRAINED
Size: 1056906528(0x3eff1d20) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
Pool 2
Segment: GLOBAL; FLAGS: KERNARG, FINE GRAINED
Size: 1056906528(0x3eff1d20) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
Pool 3
Segment: GLOBAL; FLAGS: COARSE GRAINED
Size: 1056906528(0x3eff1d20) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: TRUE
ISA Info:


Agent 3


Name: gfx90a
Uuid: GPU-1f9de0957d137942
Marketing Name: AMD Instinct MI250X/MI250
Vendor Name: AMD
Feature: KERNEL_DISPATCH
Profile: BASE_PROFILE
Float Round Mode: NEAR
Max Queue Number: 128(0x80)
Queue Min Size: 64(0x40)
Queue Max Size: 131072(0x20000)
Queue Type: MULTI
Node: 2
Device Type: GPU
Cache Info:
L1: 16(0x10) KB
L2: 8192(0x2000) KB
Chip ID: 29708(0x740c)
ASIC Revision: 1(0x1)
Cacheline Size: 64(0x40)
Max Clock Freq. (MHz): 1700
BDFID: 10496
Internal Node ID: 2
Compute Unit: 104
SIMDs per CU: 4
Shader Engines: 8
Shader Arrs. per Eng.: 1
WatchPts on Addr. Ranges:4
Features: KERNEL_DISPATCH
Fast F16 Operation: TRUE
Wavefront Size: 64(0x40)
Workgroup Max Size: 1024(0x400)
Workgroup Max Size per Dimension:
x 1024(0x400)
y 1024(0x400)
z 1024(0x400)
Max Waves Per CU: 32(0x20)
Max Work-item Per CU: 2048(0x800)
Grid Max Size: 4294967295(0xffffffff)
Grid Max Size per Dimension:
x 4294967295(0xffffffff)
y 4294967295(0xffffffff)
z 4294967295(0xffffffff)
Max fbarriers/Workgrp: 32
Pool Info:
Pool 1
Segment: GLOBAL; FLAGS: COARSE GRAINED
Size: 67092480(0x3ffc000) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: FALSE
Pool 2
Segment: GLOBAL; FLAGS: FINE GRAINED
Size: 67092480(0x3ffc000) KB
Allocatable: TRUE
Alloc Granule: 4KB
Alloc Alignment: 4KB
Accessible by all: FALSE
Pool 3
Segment: GROUP
Size: 64(0x40) KB
Allocatable: FALSE
Alloc Granule: 0KB
Alloc Alignment: 0KB
Accessible by all: FALSE
ISA Info:
ISA 1
Name: amdgcn-amd-amdhsa--gfx90a:sramecc+:xnack-
Machine Models: HSA_MACHINE_MODEL_LARGE
Profiles: HSA_PROFILE_BASE
Default Rounding Mode: NEAR
Default Rounding Mode: NEAR
Fast f16: TRUE
Workgroup Max Size: 1024(0x400)
Workgroup Max Size per Dimension:
x 1024(0x400)
y 1024(0x400)
z 1024(0x400)
Grid Max Size: 4294967295(0xffffffff)
Grid Max Size per Dimension:
x 4294967295(0xffffffff)
y 4294967295(0xffffffff)
z 4294967295(0xffffffff)
FBarrier Max Size: 32
*** Done ***

Additional Information

No response

@ppanchad-amd
Copy link

@eugen-ajechiloae-clearml Apologies for the lack of response. Can you please check if your issue still exists with the latest ROCm 6.2? If not, please close the ticket. Thanks!

@eugen-ajechiloae-clearml
Copy link
Author

Hi @ppanchad-amd ! It looks like the issue still exists

@ppanchad-amd
Copy link

@eugen-ajechiloae-clearml Internal ticket is created to fix this issue. Thanks!

@schung-amd
Copy link

Hi @eugen-ajechiloae-clearml, I've reproduced this, and after digging into the source code, it seems like rsmi_compute_process_info_get does indeed read only the process id and pasid (i.e. this is expected behaviour and not a configuration issue). However, the documentation does not indicate whether this is intentional or an oversight, so I'm reaching out to the internal component team to find out what's going on here. Thanks!

@schung-amd
Copy link

After speaking with the internal team, rsmi_compute_process_info_get() is intended to only retrieve process id and pasid as a first step before calling rsmi_compute_process_info_by_pid_get() for the full information, just as you have done in the working code. We're working on a documentation update that will make this clear. Thanks for bringing this to our attention!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants