[Windows][Arc A770] OpenCL transfers and LOW-throttle clFinish stall despite completed monitored fence

Start with the standalone reproducer described in the issue and run the baseline command on the stated A770 and Windows configuration; compare it with the hook diagnostics and LOW-throttle clFinish case. The issue establishes a reproducible wait but does not identify the responsible runtime, kernel driver, or scheduler component. Done means locating and fixing the cause so completed OpenCL work returns promptly, then verifying transfers and clFinish without diagnostic recovery.

Pre-submission Checklist

• I am using the latest GPU driver version (download center)
• I have searched for similar issues and found none

GPU Hardware

Intel(R) Arc(TM) A770 Graphics, 16 GB

GPU Detailed Information

Read using Get-CimInstance Win32_VideoController:

Name : Intel(R) Arc(TM) A770 Graphics
DriverVersion : 32.0.101.9150
DriverDate : 2026-10-07 20:00:00 (local PowerShell display)
VideoProcessor : Intel(R) Arc(TM) A770 Graphics Family
AdapterRAM : 4293918720
PNPDeviceID : PCI\VEN_8086&DEV_56A0&SUBSYS_38881025&REV_08\6&1C332D3C&0&000800DC

The AdapterRAM value above is the raw WMI result; the tested card has 16 GB VRAM.
OpenCL runtime igdrcl64.dll and Intel kernel driver both report 32.0.101.9150.
igdrcl64.dll SHA-256:
0AC5822E42CDC7642EA96AB99B35E3FF92254BCCFE2E08F808914D425AC4DEF5

Another installed Intel adapter:
Name : Intel(R) UHD Graphics 770
DriverVersion : 32.0.101.7088
PNPDeviceID : PCI\VEN_8086&DEV_4680&SUBSYS_88821043&REV_0C\3&11583659&0&10

Driver Installation Details

Installed using Intel Driver & Support Assistant.

Windows Build Information

Microsoft Windows 11 Pro, version 25H2
Full build: 26200.9711
Win32_OperatingSystem Version: 10.0.26200
DisplayVersion=25H2, CurrentBuild=26200, UBR=9711 in the recorded environment.

Actual Behavior

Small OpenCL host/device transfers intermittently stall for approximately 70 seconds on this system. The original application freezes during the call and can subsequently continue with correct results.

A standalone loop runs an approximately 20 ms ALU kernel, calls clFinish, then performs eight blocking 32-byte clEnqueueWriteBuffer calls. An unhooked recheck stalled on write 23,661 for 70.254 seconds. Stack samples at 3 and 23 seconds showed win32u!NtGdiDdDDIWaitForSynchronizationObjectFromCpu, with unchanged application-thread CPU time. This establishes a prolonged wait, not a proven permanent hang, and does not require the diagnostic hook.

Separate instrumented runs show the CPU-visible monitored fence already at the requested target while the original synchronous D3DKMTWaitForSynchronizationObjectFromCpu remains pending. The transfer path waits on a copy-context fence. Blocking reads are affected too.

The same signature also occurs on a compute-context fence in clFinish after USM copy kernels when the queue uses CL_QUEUE_THROTTLE_LOW_KHR, which selects blocking waits on this driver. It therefore is not limited to host/device copy-engine transfers.

An experimental watchdog registers an additional asynchronous wait for the same device, synchronization object and already-reached fence target. This releases the original wait without writing a fence value or submitting additional GPU work. In the initial transfer/polling recovery trials, 53/53 observed stalls recovered; a subsequent LOW-throttle clFinish trial recovered 4/4. Verification passed in those runs. Later Moderate-power-policy trials recovered another 20/20 observed stalls.

This is consistent with a missed/deferred notification or wait-reevaluation problem. The responsible Intel runtime/KMD/Windows scheduler component and the mechanism behind the approximately 70-second natural recovery have not been established. The fence sample at hook entry precedes the syscall; it does not reveal the exact instant of internal wait registration.

Expected Behavior

Blocking OpenCL transfers and clFinish should return promptly once their work and required synchronization have completed. They should not remain asleep for tens of seconds with a completed fence target, or require an unrelated operation/additional wait registration to resume.

Reproduction Rate

Frequently reproduces ~ 75% - 99%

Steps to Reproduce

1. Use the above A770/Windows/driver configuration. Keep other GPU workloads idle. Run trials sequentially: other GPU activity can release a stalled wait and mask the problem.

2. Obtain the standalone reproducer repository (see reproducer information).

3. Install Visual Studio 2022 C++ Build Tools with a Windows SDK. No separate OpenCL SDK or oneAPI toolkit is needed; OpenCL headers are bundled and OpenCL.dll is loaded at runtime.

4. From the repository root in cmd.exe, run:

   build.bat
   build\oclstall.exe --device A770 --op write --busy-ms 20 --seconds 300

5. Observe WATCHDOG stack samples followed by a STALL line, typically around 70 seconds. This baseline does not enable the D3DKMT hook or recovery. Repeat if a run is clean. The requested duration is checked between operations, so a blocked API call can extend wall-clock runtime past it.

6. For fence diagnostics without recovery, run separately:

   build\oclstall.exe --device A770 --op write --busy-ms 20 --seconds 300 --hook

7. To exercise clFinish on a LOW-throttle queue, run separately:

   build\oclstall.exe --device A770 --op usm-kernel --throttle low --busy-ms 5 --seconds 300 --hook

8. The separate recovery experiment is shown in Command Line / Application Details. Do not use recovery when measuring the natural stall duration.

Is this a regression?

• Yes, this is a regression - functionality that previously worked is now broken

Last Known Working Driver Version

No response

First Known Failing Driver Version

No response

API Call Logs

These excerpts come from the reproducer's watchdog and custom D3DKMT tracing, not CLIntercept or Unitrace. Full evidence files will be included with the reproducer repository.

Unhooked baseline (results/recheck_plain_write.log):

21:22:42.813 WATCHDOG: call #23661 running 3.0 s: write 32 B buffer 0 (round 2957, 0.6 ms after kernel) (main thread cpu: kernel 1.69 s, user 67.42 s)
0 win32u!NtGdiDdDDIWaitForSynchronizationObjectFromCpu+0x14 (rva 0x60a4)
14 OpenCL!clEnqueueWriteBuffer+0xfb (rva 0xa83b)
21:23:02.784 WATCHDOG: call #23661 still running after 23.0 s (main thread cpu: kernel 1.69 s, user 67.42 s)
21:23:50.026 STALL 70.254 s: write 32 B buffer 0 (round 2957, 0.6 ms after kernel)

Separate same-fence recovery run (results/recheck_probe_write.log):

handle 0x40000f80 (monitored fence): target 9911, current 9911, at entry 9910 -> ALREADY REACHED (wait still pending)
[kmt probe] same-fence async wait: status 0x00000000, event wait 0 (0=signalled, 258=timeout), elapsed 0.071 ms; original wait active=1
21:24:51.624 STALL 1.013 s: write 32 B buffer 2 (round 1238, 0.9 ms after kernel)

The approximately one-second recovery duration includes the intentional watchdog delay. It is not the natural stall duration.

Evidence paths in the forthcoming repository:

• results/recheck-20261023/evidence.txt — baseline and transfer recovery excerpts
• results/recheck-20261023/environment.json — driver/OS versions and hashes
• results/recheck-final-20261023/summary.tsv — final polling/map/USM controls
• results/recovery-finish-20261023-223009/evidence.txt and summary.json — LOW-throttle compute-fence recovery
• results/aspm-ac1-20261023-2240/ — Moderate-policy write retest
• results/aspm-ac1-finish-20261023-2243/ — Moderate-policy LOW-throttle retest

Windows Event Viewer Logs

No response

Crash Dumps / Minidumps

No response

Source Code / Reproducer

A standalone repository named arc-ocl-stall is prepared and will be uploaded separately. Repository URL: [https://github.com/1640675651/arc-ocl-stall](url)
It contains the C++ reproducer, optional D3DKMT hook, build.bat, bundled OpenCL headers, test scripts, README, and evidence excerpts.
Build: build.bat
Output: build\oclstall.exe

Command Line / Application Details

Baseline, no hook and no recovery:
build\oclstall.exe --device A770 --op write --busy-ms 20 --seconds 300

Blocking-read variant:
build\oclstall.exe --device A770 --op read --busy-ms 5 --seconds 300 --hook

Diagnostic recovery for transfers:
build\oclstall.exe --device A770 --op write --busy-ms 5 --seconds 120 --kick 5 --verify

Diagnostic recovery for LOW-throttle clFinish:
build\oclstall.exe --device A770 --op usm-kernel --throttle low --busy-ms 5 --seconds 120 --kick 5 --watch 0.5 --verify

--kick 5 automatically enables the hook. After a wait has been blocked for more than one second, it checks that the target has been reached, then registers another asynchronous KMT wait using a fresh Windows event. It does not signal or advance the fence. This is experimental diagnostic recovery, not a production fix.
Write-mode verification checks final buffer contents; read-mode verification checks every read. Successful final write verification does not verify every intermediate transfer.

oneAPI Version (if applicable)

No response

System Configuration

CPU: 12th Gen Intel(R) Core(TM) i9-12900K
RAM: 64 GiB DDR5
Motherboard: ASUSTeK COMPUTER INC. PRIME Z790-V WIFI, Rev 1.xx
Other installed GPUs: Intel UHD Graphics 770 and NVIDIA GeForce GTX 1070

Screenshots / Video

No response

Intel System Support Utility Report

No response

Additional Notes

No response