Skip to content

Add GPU memory usage retrieval and update language strings for memory usage display#1053

Merged
shm11C3 merged 2 commits into
developfrom
feat/macos/dashboard-gpu-display
Jan 25, 2026
Merged

Add GPU memory usage retrieval and update language strings for memory usage display#1053
shm11C3 merged 2 commits into
developfrom
feat/macos/dashboard-gpu-display

Conversation

@shm11C3

@shm11C3 shm11C3 commented Jan 25, 2026

Copy link
Copy Markdown
Owner

No description provided.

Copilot AI review requested due to automatic review settings January 25, 2026 08:34
@github-actions

github-actions Bot commented Jan 25, 2026

Copy link
Copy Markdown
Contributor

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 79.61% (🎯 60%) 793 / 996
🔵 Statements 77.59% (🎯 60%) 821 / 1058
🔵 Functions 70.96% (🎯 60%) 176 / 248
🔵 Branches 66.37% (🎯 60%) 227 / 342
File CoverageNo changed files found.
Generated in workflow #2118 for commit 9275cd0 by the Vitest Coverage Report Action

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds runtime GPU memory usage retrieval for macOS systems and updates the language strings to be more concise. The implementation fetches GPU memory usage via a new backend command and conditionally displays it when static memory size information is unavailable.

Changes:

  • Added GPU memory usage fetching with 3-second polling interval
  • Updated English and Japanese translation strings for GPU memory display labels (removing "Shared GPU" prefix and fixing trailing space)
  • Enhanced GPU info display logic to show dynamic memory usage as fallback when static memory size is unavailable

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
src/lang/en.json Updated translation key to simplify "memorySizeSharedUsage" label and fix trailing space
src/lang/ja.json Updated Japanese translation to match simplified English label
src/features/hardware/dashboard/components/DashboardItems.tsx Added GPU memory usage state, polling logic via useEffect, and conditional rendering based on available data

Comment thread src/features/hardware/dashboard/components/DashboardItems.tsx
Comment thread src/features/hardware/dashboard/components/DashboardItems.tsx
Comment thread src/features/hardware/dashboard/components/DashboardItems.tsx Outdated
Comment thread src/features/hardware/dashboard/components/DashboardItems.tsx Outdated
Copilot AI review requested due to automatic review settings January 25, 2026 09:12

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

Comment on lines +93 to +98
const fetchGpuMemoryUsage = async () => {
const result = await commands.getGpuMemoryUsage();
if (isError(result)) {
console.error("Failed to fetch GPU memory usage:", result);
return;
}

Copilot AI Jan 25, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error handling here is inconsistent with the established pattern in this codebase. Other similar command calls in hooks like useHardwareInfoAtom.ts (lines 22-25) and useProcessInfo.ts use the useTauriDialog().error() method to show user-facing error dialogs instead of just console.error(). This provides better user feedback when GPU memory usage cannot be retrieved.

Consider using the established error handling pattern by extracting error from useTauriDialog() and calling it when an error occurs.

Copilot uses AI. Check for mistakes.
Comment on lines +151 to +184
{(() => {
const hasMemorySize = gpu.memorySize !== "N/A";
const hasMemoryUsage = gpuMemoryUsage?.inUseBytes != null;
const memorySizeDisplay = hasMemorySize
? gpu.memorySize
: hasMemoryUsage
? (gpuMemoryUsage?.inUseBytes ?? "N/A")
: "N/A";
const memorySizeLabel = hasMemorySize
? t("shared.memorySize")
: hasMemoryUsage
? t("shared.memorySizeSharedUsage")
: t("shared.memorySize");

const showCoreCount =
gpu.memorySizeDedicated === "N/A" && os === "macos";
const dedicatedMemoryDisplay = showCoreCount
? (gpu.coreCount ?? "N/A")
: gpu.memorySizeDedicated;
const dedicatedMemoryLabel = showCoreCount
? t("shared.coreCount")
: t("shared.memorySizeDedicated");

return (
<InfoTable
data={{
[t("shared.name")]: gpu.name,
[t("shared.vendor")]: gpu.vendorName,
[memorySizeLabel]: memorySizeDisplay,
[dedicatedMemoryLabel]: dedicatedMemoryDisplay,
}}
/>
);
})()}

Copilot AI Jan 25, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GPU memory usage is fetched globally (once per component), but the component renders multiple GPUs in a loop. The getGpuMemoryUsage command documentation indicates it returns memory usage for the GPU, but when there are multiple GPUs (hardwareInfo.gpus is an array), this global gpuMemoryUsage state is being applied to each GPU individually in the map() function.

According to the backend documentation in bindings.ts, the command is best-effort and currently only implemented for macOS, so it may return data for only one GPU. This could lead to incorrect memory usage display when multiple GPUs are present. Consider either: (1) documenting that memory usage only applies to the first/primary GPU, or (2) matching the GPU memory usage to a specific GPU by index/ID if the backend supports it.

Copilot uses AI. Check for mistakes.
const memorySizeDisplay = hasMemorySize
? gpu.memorySize
: hasMemoryUsage
? (gpuMemoryUsage?.inUseBytes ?? "N/A")

Copilot AI Jan 25, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nullish coalescing operator here is redundant. The expression gpuMemoryUsage?.inUseBytes ?? "N/A" will already handle null/undefined cases, so wrapping it in parentheses and applying another ?? "N/A" is unnecessary since the inner expression already guarantees a non-null value.

Suggested change
? (gpuMemoryUsage?.inUseBytes ?? "N/A")
? gpuMemoryUsage?.inUseBytes

Copilot uses AI. Check for mistakes.
@shm11C3 shm11C3 merged commit c39df37 into develop Jan 25, 2026
22 checks passed
@shm11C3 shm11C3 deleted the feat/macos/dashboard-gpu-display branch January 25, 2026 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants