Public bug reported: BugLink: https://bugs.launchpad.net/bugs/2162038
[ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM module. Currently, the mechanisms above works independently. However, on APU systems, because total physical memory is shared among the above and is partitioned into them, the calculation needs to take the total physical memory into account. Otherwise the driver would be double-booking physical memory, leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Affects: linux-oem-7.0 (Ubuntu) Importance: Undecided Assignee: Leo Lin (0xff07) Status: New ** Changed in: linux-oem-7.0 (Ubuntu) Assignee: (unassigned) => Leo Lin (0xff07) ** Description changed: [ Impact ] - On AMD APUs, there are few ways to tweak memory being used by the amdgpu - driver. Notably: + On AMD APU systems, there are few ways to tweak memory being used by the + amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM modules. Currently, the mechanisms above works independently. However, because physical memory is partitioned into the usage above on APU systems, the calculation needs to take the total physical memory into account. Otherwise the driver would be double-booking physical memory, leading to issues like [1]. - [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] - [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. - [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. - [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Description changed: [ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM modules. Currently, the mechanisms above works independently. However, because - physical memory is partitioned into the usage above on APU systems, the - calculation needs to take the total physical memory into account. - Otherwise the driver would be double-booking physical memory, leading to - issues like [1]. + total physical memory is shared among the above and is partitioned into + them, the calculation needs to take the total physical memory into + account. Otherwise the driver would be double-booking physical memory, + leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Description changed: + BugLink: https://bugs.launchpad.net/ubuntu/bugs/2162038 + [ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM modules. Currently, the mechanisms above works independently. However, because total physical memory is shared among the above and is partitioned into them, the calculation needs to take the total physical memory into account. Otherwise the driver would be double-booking physical memory, leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Description changed: - BugLink: https://bugs.launchpad.net/ubuntu/bugs/2162038 + BugLink: https://bugs.launchpad.net/bugs/2162038 [ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM modules. Currently, the mechanisms above works independently. However, because total physical memory is shared among the above and is partitioned into them, the calculation needs to take the total physical memory into account. Otherwise the driver would be double-booking physical memory, leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Description changed: BugLink: https://bugs.launchpad.net/bugs/2162038 [ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - - GTT size can be tweaked by module parameters in the TTM modules. + - GTT size can be tweaked by module parameters in the TTM module. Currently, the mechanisms above works independently. However, because total physical memory is shared among the above and is partitioned into them, the calculation needs to take the total physical memory into account. Otherwise the driver would be double-booking physical memory, leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ ** Description changed: BugLink: https://bugs.launchpad.net/bugs/2162038 [ Impact ] On AMD APU systems, there are few ways to tweak memory being used by the amdgpu driver. Notably: - VRAM size can be tweaked by: UMA carveout by the BIOS/sysfs interfaces. - GTT size can be tweaked by module parameters in the TTM module. - Currently, the mechanisms above works independently. However, because - total physical memory is shared among the above and is partitioned into - them, the calculation needs to take the total physical memory into - account. Otherwise the driver would be double-booking physical memory, - leading to issues like [1]. + Currently, the mechanisms above works independently. However, on APU + systems, because total physical memory is shared among the above and is + partitioned into them, the calculation needs to take the total physical + memory into account. Otherwise the driver would be double-booking + physical memory, leading to issues like [1]. [ Fix ] Cherry-pick the following commit: - drm/amdgpu: cap GTT size to physical RAM on APUs[2] [ Test Plan ] - Boot into the kernel with a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS/sysfs by increasing the UMA Frame Buffer Size (VRAM) to 64GB and reboot. - The previously set GTT value (~100GB) should be capped to the non-carveout space. [ Where the problems could occur ] Because the old driver is double-counting memory sizes, a user with this update may feel that memory become less, when in fact that memory is double-counted and never exists. This impacts memory calculation on GTT for APU systems. [ Additional Information ] [1] https://github.com/ROCm/ROCm/issues/6004 [2] https://lore.kernel.org/amd-gfx/[email protected]/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2162038 Title: [SRU] Fix incorrect GTT calculation on the APU systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oem-7.0/+bug/2162038/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
