Pre-submission Checklist
GPU Hardware
Intel(R) Arc(TM) Pro B65 Graphics — 32 GB GDDR6, PCI ID 8086:e222
GPU Detailed Information
PowerShell GPU enumeration:
Name : Intel(R) Arc(TM) Pro B65 Graphics
DriverVersion : 32.0.101.8805
DriverDate : 20260707000000.000000-000
VideoProcessor : Intel(R) Arc(TM) Pro B65 Graphics Family
AdapterRAM : 2147479552
PNPDeviceID : PCI\VEN_8086&DEV_E222&SUBSYS_60271849&REV_00\8&11805000&0&000800000039
Name : Intel(R) Arc(TM) 140V GPU (16GB)
DriverVersion : 32.0.101.8991
DriverDate : 20260824000000.000000-000
VideoProcessor : Intel(R) Arc(TM) 140V GPU (16GB) Family
AdapterRAM : 4293918720
PNPDeviceID : PCI\VEN_8086&DEV_64A0&SUBSYS_1E131043&REV_04\3&11583659&0&10
Raw Level Zero reproducer selected:
Device name : Intel(R) Arc(TM) Pro B65 Graphics
Vendor ID : 0x8086
Device ID : 0xe222
Reported device memory : 33514291200 bytes
Reported maxMemAllocSize : 33514291200 bytes
Note: Win32_VideoController.AdapterRAM is a legacy 32-bit-limited field and
therefore does not report the actual 32 GB VRAM capacity of the B65.
Driver Installation Details
- Installation method: Intel Driver & Support Assistant (Intel DSA)
- Intel Arc Pro B65 driver: 32.0.101.8805
- Driver date reported by Windows: 2026-07-07
- Current Arc Pro package designation: Q2.26.R2
Windows Build Information
Windows 11 Home, version 25H2
OS build: 26200.9168
Registry values:
EditionID : Core
DisplayVersion : 25H2
CurrentBuild : 26200
UBR : 9168
Level Zero loader:
FileVersion : 1.32.0
ProductVersion : 1.32.0
FileName : C:\Windows\System32\ze_loader.dll
Actual Behavior
A standalone raw Level Zero reproducer on Windows allocates 16 GiB of device memory on a single Intel Arc Pro B65 using zeMemAllocDevice().
The executable imports ze_loader.dll and does not import SYCL or Unified Runtime libraries. No llama.cpp, model, GGUF, mmap, PyTorch, oneDNN, KV cache, or multi-GPU workload is involved.
Two distinct effects are observed:
-
At device allocation time, process PrivateBytes immediately rises by approximately the allocation size (~16.28 GiB), while the physical private working set remains only ~0.10 GiB.
-
After the entire device allocation is touched by the GPU and synchronized, the process later acquires a physical WorkingSetPrivate close to the complete allocation size while the application itself is idle.
On a 32 GB host this drives Available RAM toward zero and makes normal desktop use impractical.
Pre-touch control:
After zeMemAllocDevice(16 GiB), the following remained essentially flat for more than 120 seconds while the allocation was not touched by the GPU:
PrivateBytes ~16.279 GiB
WorkingSetPrivate ~0.099 GiB
Available system RAM ~16.8 GiB
Post-touch reproduction:
After a full GPU fill/touch of the 16 GiB allocation followed by synchronization, while the application was idle:
Timestamp PrivateBytes WorkingSetPrivate Available RAM
11:36:24 16.282 GiB 0.849 GiB 16.073 GiB
11:36:30 16.282 GiB 7.099 GiB 9.481 GiB
11:36:35 16.282 GiB 12.349 GiB 4.532 GiB
11:36:42 16.282 GiB 16.160 GiB 0.769 GiB
NonPrivateWS remains very small (~0.06 GiB at the plateau), so the large resident set is process-private rather than a file-backed mapping.
A separate post-touch 16 GiB run showed the same qualitative behavior.
No crash or TDR is required to observe the problem.
Expected Behavior
A 16 GiB VRAM device allocation on a 32 GB discrete Intel Arc Pro B65 should not cause the owning Windows process to later consume an additional ~16 GiB of physically resident private host RAM while the application is idle and VRAM is not oversubscribed.
If Windows/Level Zero requires virtual commit or pageable backing metadata for device allocations, that backing should not automatically become resident 1:1 in physical system RAM solely because the device allocation was touched, unless such residency is required for correctness.
The current behavior makes otherwise valid 16-18 GiB GPU inference workloads impractical on a 32 GB Windows host despite sufficient dedicated VRAM.
Reproduction Rate
Always reproduces - 100%
Steps to Reproduce
-
Build the standalone raw Level Zero reproducer on Windows.
-
Run:
.\build\bin\raw-level-zero-memory-repro.exe --size-gib 16 --pre-touch-seconds 120 --sleep-seconds 120
-
Monitor the reproducer PID once per second, recording:
- process WorkingSet
- WorkingSetPrivate
- PrivateBytes
- system Available RAM
- Committed / CommitLimit
- pagefile usage
-
During the pre-touch hold, observe:
PrivateBytes ~= 16.28 GiB
WorkingSetPrivate ~= 0.10 GiB
-
Let the program GPU-fill/touch the entire allocation and synchronize.
-
Leave the process idle and continue monitoring.
-
Observe the process private working set later grow toward the full 16 GiB allocation size, with system Available RAM falling correspondingly.
Is this a regression?
Last Known Working Driver Version
No response
First Known Failing Driver Version
No response
API Call Logs
The reproducer is raw Level Zero and intentionally minimal.
No UnitTrace capture has been collected yet. The key API sequence is:
zeInit
GPU enumeration / B65 selection
zeContextCreate
zeMemAllocDevice(16 GiB)
command queue/list creation
GPU fill/touch across the entire allocation
synchronize
idle
zeMemFree / resource destruction
If maintainers request UnitTrace output, I can capture it on the same 16 GiB reproducer.
Windows Event Viewer Logs
No crash or TDR is required to reproduce the issue.
The raw Level Zero reproducer exits cleanly, and no relevant Windows Event Viewer error is required for the host-memory behavior to occur.
Crash Dumps / Minidumps
Not applicable. The reproducer does not crash or hang and exits cleanly.
Source Code / Reproducer
Standalone reproducer workspace:
C:\local-inference-lab\sycl-memory-repro
Files:
README.md
src/raw_level_zero.cpp
src/sycl_repro.cpp
CMakeLists.txt
build.ps1
monitor-memory.ps1
empty-working-set.ps1
run-sycl.cmd
The raw executable was verified to import ze_loader.dll but no SYCL or Unified Runtime libraries.
Build:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1
Run:
.\build\bin\raw-level-zero-memory-repro.exe --size-gib 16 --pre-touch-seconds 120 --sleep-seconds 120
Monitor:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\monitor-memory.ps1 -TargetPid
sycl-memory-repro.zip
Command Line / Application Details
Run from PowerShell:
cd C:\local-inference-lab\sycl-memory-repro
.\build\bin\raw-level-zero-memory-repro.exe --size-gib 16
--pre-touch-seconds 120 `
--sleep-seconds 120
The program explicitly selects:
Intel(R) Arc(TM) Pro B65 Graphics
Allocation API:
zeMemAllocDevice
The test has separate stages:
A - startup
B - B65 selected
C - 16 GiB device allocation complete, not touched
D - entire allocation filled/touched on GPU and synchronized
E - application idle while allocation/context/queue remain alive
In a second PowerShell window:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\monitor-memory.ps1
-TargetPid
The monitor samples process WorkingSet, WorkingSetPrivate, PrivateBytes,
system Available RAM, Commit/CommitLimit and pagefile usage once per second.
oneAPI Version (if applicable)
The raw reproducer does not use SYCL or Unified Runtime at runtime.
It was built using the locally installed Intel oneAPI 2026.1 development toolchain,
but the resulting raw executable was verified to import ze_loader.dll and no SYCL
or Unified Runtime libraries.
Windows Level Zero loader:
FileVersion : 1.32.0
ProductVersion : 1.32.0
FileName : C:\Windows\System32\ze_loader.dll
System Configuration
System:
ASUS Zenbook S14 OLED UX5406S / UX5406SA
CPU:
Intel Core Ultra 7 258V (Lunar Lake)
System memory:
32 GB LPDDR5X-8533
Integrated GPU:
Intel(R) Arc(TM) 140V GPU (16GB)
Discrete GPU under test:
Intel(R) Arc(TM) Pro B65 Graphics
32 GB GDDR6
PCI ID 8086:e222
eGPU connection:
AOOSTAR AG02
ASMedia ASM2464PDX
USB4 / Thunderbolt 4 class connection
Operating system:
Windows 11 Home 25H2
Build 26200.9168
Screenshots / Video
No response
Intel System Support Utility Report
No response
Additional Notes
Possibly related Intel Compute Runtime issues:
This report appears materially different:
- Windows 11 rather than Linux
- a single discrete Arc Pro B65 is sufficient
- no peer device or peer-residency call is required
- raw Level Zero reproducer
- no SYCL / Unified Runtime at runtime
- no model or inference framework required
The issue was originally observed while trying to run Qwen3.8-27B inference on the B65 under Windows. llama.cpp/SYCL could reach approximately 16 tok/s decode, but the associated host-memory pressure made the Windows desktop impractical to use.
The standalone reproducer was created specifically to remove llama.cpp, Qwen, GGUF/model mmap, SYCL, Unified Runtime and multi-GPU behavior from the experiment.
The pre-touch control is important: zeMemAllocDevice(16 GiB) immediately creates approximately 16.28 GiB of PrivateBytes, but WorkingSetPrivate remains approximately 0.10 GiB for more than 120 seconds if the allocation is not touched by the GPU. The large physical private working set appears only after the GPU has touched/synchronized the allocation.
I am happy to run additional controlled variants requested by maintainers, including different allocation sizes, explicit residency APIs, UnitTrace capture, or different driver versions.
Pre-submission Checklist
GPU Hardware
Intel(R) Arc(TM) Pro B65 Graphics — 32 GB GDDR6, PCI ID 8086:e222
GPU Detailed Information
PowerShell GPU enumeration:
Name : Intel(R) Arc(TM) Pro B65 Graphics
DriverVersion : 32.0.101.8805
DriverDate : 20260707000000.000000-000
VideoProcessor : Intel(R) Arc(TM) Pro B65 Graphics Family
AdapterRAM : 2147479552
PNPDeviceID : PCI\VEN_8086&DEV_E222&SUBSYS_60271849&REV_00\8&11805000&0&000800000039
Name : Intel(R) Arc(TM) 140V GPU (16GB)
DriverVersion : 32.0.101.8991
DriverDate : 20260824000000.000000-000
VideoProcessor : Intel(R) Arc(TM) 140V GPU (16GB) Family
AdapterRAM : 4293918720
PNPDeviceID : PCI\VEN_8086&DEV_64A0&SUBSYS_1E131043&REV_04\3&11583659&0&10
Raw Level Zero reproducer selected:
Device name : Intel(R) Arc(TM) Pro B65 Graphics
Vendor ID : 0x8086
Device ID : 0xe222
Reported device memory : 33514291200 bytes
Reported maxMemAllocSize : 33514291200 bytes
Note: Win32_VideoController.AdapterRAM is a legacy 32-bit-limited field and
therefore does not report the actual 32 GB VRAM capacity of the B65.
Driver Installation Details
Windows Build Information
Windows 11 Home, version 25H2
OS build: 26200.9168
Registry values:
EditionID : Core
DisplayVersion : 25H2
CurrentBuild : 26200
UBR : 9168
Level Zero loader:
FileVersion : 1.32.0
ProductVersion : 1.32.0
FileName : C:\Windows\System32\ze_loader.dll
Actual Behavior
A standalone raw Level Zero reproducer on Windows allocates 16 GiB of device memory on a single Intel Arc Pro B65 using zeMemAllocDevice().
The executable imports ze_loader.dll and does not import SYCL or Unified Runtime libraries. No llama.cpp, model, GGUF, mmap, PyTorch, oneDNN, KV cache, or multi-GPU workload is involved.
Two distinct effects are observed:
At device allocation time, process PrivateBytes immediately rises by approximately the allocation size (~16.28 GiB), while the physical private working set remains only ~0.10 GiB.
After the entire device allocation is touched by the GPU and synchronized, the process later acquires a physical WorkingSetPrivate close to the complete allocation size while the application itself is idle.
On a 32 GB host this drives Available RAM toward zero and makes normal desktop use impractical.
Pre-touch control:
After zeMemAllocDevice(16 GiB), the following remained essentially flat for more than 120 seconds while the allocation was not touched by the GPU:
PrivateBytes ~16.279 GiB
WorkingSetPrivate ~0.099 GiB
Available system RAM ~16.8 GiB
Post-touch reproduction:
After a full GPU fill/touch of the 16 GiB allocation followed by synchronization, while the application was idle:
Timestamp PrivateBytes WorkingSetPrivate Available RAM
11:36:24 16.282 GiB 0.849 GiB 16.073 GiB
11:36:30 16.282 GiB 7.099 GiB 9.481 GiB
11:36:35 16.282 GiB 12.349 GiB 4.532 GiB
11:36:42 16.282 GiB 16.160 GiB 0.769 GiB
NonPrivateWS remains very small (~0.06 GiB at the plateau), so the large resident set is process-private rather than a file-backed mapping.
A separate post-touch 16 GiB run showed the same qualitative behavior.
No crash or TDR is required to observe the problem.
Expected Behavior
A 16 GiB VRAM device allocation on a 32 GB discrete Intel Arc Pro B65 should not cause the owning Windows process to later consume an additional ~16 GiB of physically resident private host RAM while the application is idle and VRAM is not oversubscribed.
If Windows/Level Zero requires virtual commit or pageable backing metadata for device allocations, that backing should not automatically become resident 1:1 in physical system RAM solely because the device allocation was touched, unless such residency is required for correctness.
The current behavior makes otherwise valid 16-18 GiB GPU inference workloads impractical on a 32 GB Windows host despite sufficient dedicated VRAM.
Reproduction Rate
Always reproduces - 100%
Steps to Reproduce
Build the standalone raw Level Zero reproducer on Windows.
Run:
.\build\bin\raw-level-zero-memory-repro.exe --size-gib 16 --pre-touch-seconds 120 --sleep-seconds 120
Monitor the reproducer PID once per second, recording:
During the pre-touch hold, observe:
PrivateBytes ~= 16.28 GiB
WorkingSetPrivate ~= 0.10 GiB
Let the program GPU-fill/touch the entire allocation and synchronize.
Leave the process idle and continue monitoring.
Observe the process private working set later grow toward the full 16 GiB allocation size, with system Available RAM falling correspondingly.
Is this a regression?
Last Known Working Driver Version
No response
First Known Failing Driver Version
No response
API Call Logs
The reproducer is raw Level Zero and intentionally minimal.
No UnitTrace capture has been collected yet. The key API sequence is:
zeInit
GPU enumeration / B65 selection
zeContextCreate
zeMemAllocDevice(16 GiB)
command queue/list creation
GPU fill/touch across the entire allocation
synchronize
idle
zeMemFree / resource destruction
If maintainers request UnitTrace output, I can capture it on the same 16 GiB reproducer.
Windows Event Viewer Logs
No crash or TDR is required to reproduce the issue.
The raw Level Zero reproducer exits cleanly, and no relevant Windows Event Viewer error is required for the host-memory behavior to occur.
Crash Dumps / Minidumps
Not applicable. The reproducer does not crash or hang and exits cleanly.
Source Code / Reproducer
Standalone reproducer workspace:
C:\local-inference-lab\sycl-memory-repro
Files:
README.md
src/raw_level_zero.cpp
src/sycl_repro.cpp
CMakeLists.txt
build.ps1
monitor-memory.ps1
empty-working-set.ps1
run-sycl.cmd
The raw executable was verified to import ze_loader.dll but no SYCL or Unified Runtime libraries.
Build:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1
Run:
.\build\bin\raw-level-zero-memory-repro.exe --size-gib 16 --pre-touch-seconds 120 --sleep-seconds 120
Monitor:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\monitor-memory.ps1 -TargetPid
sycl-memory-repro.zip
Command Line / Application Details
Run from PowerShell:
cd C:\local-inference-lab\sycl-memory-repro
.\build\bin\raw-level-zero-memory-repro.exe
--size-gib 16--pre-touch-seconds 120 `
--sleep-seconds 120
The program explicitly selects:
Intel(R) Arc(TM) Pro B65 Graphics
Allocation API:
zeMemAllocDevice
The test has separate stages:
A - startup
B - B65 selected
C - 16 GiB device allocation complete, not touched
D - entire allocation filled/touched on GPU and synchronized
E - application idle while allocation/context/queue remain alive
In a second PowerShell window:
powershell.exe -NoProfile -ExecutionPolicy Bypass
-File .\monitor-memory.ps1-TargetPid
The monitor samples process WorkingSet, WorkingSetPrivate, PrivateBytes,
system Available RAM, Commit/CommitLimit and pagefile usage once per second.
oneAPI Version (if applicable)
The raw reproducer does not use SYCL or Unified Runtime at runtime.
It was built using the locally installed Intel oneAPI 2026.1 development toolchain,
but the resulting raw executable was verified to import ze_loader.dll and no SYCL
or Unified Runtime libraries.
Windows Level Zero loader:
FileVersion : 1.32.0
ProductVersion : 1.32.0
FileName : C:\Windows\System32\ze_loader.dll
System Configuration
System:
ASUS Zenbook S14 OLED UX5406S / UX5406SA
CPU:
Intel Core Ultra 7 258V (Lunar Lake)
System memory:
32 GB LPDDR5X-8533
Integrated GPU:
Intel(R) Arc(TM) 140V GPU (16GB)
Discrete GPU under test:
Intel(R) Arc(TM) Pro B65 Graphics
32 GB GDDR6
PCI ID 8086:e222
eGPU connection:
AOOSTAR AG02
ASMedia ASM2464PDX
USB4 / Thunderbolt 4 class connection
Operating system:
Windows 11 Home 25H2
Build 26200.9168
Screenshots / Video
No response
Intel System Support Utility Report
No response
Additional Notes
Possibly related Intel Compute Runtime issues:
This report appears materially different:
The issue was originally observed while trying to run Qwen3.8-27B inference on the B65 under Windows. llama.cpp/SYCL could reach approximately 16 tok/s decode, but the associated host-memory pressure made the Windows desktop impractical to use.
The standalone reproducer was created specifically to remove llama.cpp, Qwen, GGUF/model mmap, SYCL, Unified Runtime and multi-GPU behavior from the experiment.
The pre-touch control is important: zeMemAllocDevice(16 GiB) immediately creates approximately 16.28 GiB of PrivateBytes, but WorkingSetPrivate remains approximately 0.10 GiB for more than 120 seconds if the allocation is not touched by the GPU. The large physical private working set appears only after the GPU has touched/synchronized the allocation.
I am happy to run additional controlled variants requested by maintainers, including different allocation sizes, explicit residency APIs, UnitTrace capture, or different driver versions.