I have a concrete example of this. The game "The Conquest of Go" uses the the program KataGo for playing and analysis of games. There is an OpenCL version included, but it does not work. I investigated this with a wrapper script to intercept the KataGo starts (and I also used AI, yes). Here is the report that the AI drafted. If came to the conclusion that this is an proton issue.

The AI included some log output captured by the wrapper shell script. I can provide the wrapper, if required.

Proton bug report draft: builtin Wine OpenCL fails to enumerate NVIDIA platform under pressure-vessel

Summary

Under Proton Hotfix on Linux, a Windows application that uses OpenCL via Wine's builtin OpenCL.dll reaches clGetPlatformIDs, then exits cleanly without enumerating any OpenCL platform or producing tuner output.

The same application and same prefix work under local host Wine, where NVIDIA OpenCL is enumerated successfully and KataGo autotuning starts.

The failure appears specific to the Proton plus pressure-vessel path rather than the application itself.

Related existing reports

• Proton issue [#7537](/issue/ValveSoftware/Proton/7537): OpenCL missing, Games depending on it fail.
  https://github.com/ValveSoftware/Proton/issues/7537
  This is the closest existing match. It reports that games requiring OpenCL work in vanilla Wine but fail under Proton.
• steam-runtime issue [#282](/issue/ValveSoftware/Proton/282): pressure-vessel fails with could not find libnvidia-fatbinaryloader.so
  https://github.com/ValveSoftware/steam-runtime/issues/282
  This is older and not the same bug, but it is relevant background because it shows previous pressure-vessel problems around NVIDIA library exposure.

Affected application

• Game: The Conquest of Go
• Steam app ID: 1264970
• OpenCL consumer: shipped KataGo OpenCL backend

Expected result

The application should detect the NVIDIA OpenCL platform and begin autotuning, as it does under local Wine.

Actual result

Under Proton Hotfix, the application:

• loads Wine builtin OpenCL.dll
• reaches clGetPlatformIDs
• logs Tuner starting...
• exits with code 0
• produces no OpenCL tuning files in the application's LocalLow data directory

Environment

• Host OS: Linux
• Proton version: Proton Hotfix
• Runtime container: pressure-vessel / Steam Linux Runtime
• GPU vendor: NVIDIA
• NVIDIA OpenCL library visible on host: libnvidia-opencl.so.580.159.03
• Host Wine comparison that works: /usr/bin/wine, version wine-10.0 (Ubuntu 10.0~repack-12ubuntu1)

Reproduction

1. Install and run The Conquest of Go through Steam with Proton Hotfix on Linux.
2. Trigger KataGo OpenCL calibration from inside the game.
3. Observe that the calibration path exits quickly and no tuning output is written. (Note by human: First evidence is that game falls back to AVX2, then Eigen version, when trying to save prefs with OpenCL version set)

Comparison that succeeds

Using local host Wine with the same game prefix, the shipped KataGo OpenCL binary is able to enumerate the NVIDIA platform and start autotuning.

This strongly suggests the issue is in Proton plus pressure-vessel OpenCL handling rather than in the application.

Supporting evidence

Proton run environment

From StreamingAssets/KataGo/OpenCL/wrapper-logs/latest-wrapper.log:

WINE_BIN=/home/steam-library/steamapps/common/Proton Hotfix/files/bin/wine
EFFECTIVE_WINEDLLOVERRIDES=opencl=b;steam.exe=b;dotnetfx35.exe=b;dotnetfx35setup.exe=b;beclient.dll=b,n;beclient_x64.dll=b,n;winebth.sys=d;d3d11=n;d3d10core=n;d3d9=n;dxgi=n;d3d12=n;d3d12core=n;nvapi64=n;nvofapi64=n;nvapi=n;nvcuda=b
EFFECTIVE_WINEDEBUG=+timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree,+opencl
EFFECTIVE_OCL_ICD_VENDORS=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-vendors
EFFECTIVE_LD_LIBRARY_PATH=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-libs:/run/host/usr/lib/i386-linux-gnu:/run/host/usr/lib/x86_64-linux-gnu:...
EXIT_CODE=0

From StreamingAssets/KataGo/OpenCL/wrapper-logs/latest-env.log:

WINEDLLOVERRIDES=opencl=b;steam.exe=b;dotnetfx35.exe=b;dotnetfx35setup.exe=b;beclient.dll=b,n;beclient_x64.dll=b,n;winebth.sys=d;d3d11=n;d3d10core=n;d3d9=n;dxgi=n;d3d12=n;d3d12core=n;nvapi64=n;nvofapi64=n;nvapi=n;nvcuda=b
WINEDEBUG=+timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree,+opencl
OCL_ICD_VENDORS=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-vendors
OPENCL_VENDOR_PATH=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-vendors
LD_LIBRARY_PATH=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-libs:/run/host/usr/lib/i386-linux-gnu:/run/host/usr/lib/x86_64-linux-gnu:...

Proton stderr excerpt

From StreamingAssets/KataGo/OpenCL/wrapper-logs/latest-stderr.log:

Loaded L"S:\\common\\The Conquest of Go\\The Conquest of Go_Data\\StreamingAssets\\KataGo\\OpenCL\\OpenCL.dll" ... : builtin
2026-05-25 13:58:59+0200: Loading model...
2026-05-25 13:59:01+0200: Querying system devices...
trace:opencl:clGetPlatformIDs (...)
2026-05-25 13:59:01+0200: Tuner starting...

After this, the process exits cleanly without any detected OpenCL platform or tuning output.

OpenCL runtime visibility inside pressure-vessel

From StreamingAssets/KataGo/OpenCL/wrapper-logs/run-2026-05-25T13_56_53_02_00-opencl-runtime.log:

OCL_ICD_VENDORS=/home/steam-library/steamapps/common/The Conquest of Go/The Conquest of Go_Data/StreamingAssets/KataGo/OpenCL/opencl-vendors
LD_LIBRARY_PATH=/run/host/usr/lib/i386-linux-gnu:/run/host/usr/lib/x86_64-linux-gnu:...
/run/host/usr/lib/i386-linux-gnu/libnvidia-opencl.so.580.159.03
/run/host/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.580.159.03
DIR /run/host/etc/OpenCL/vendors
/run/host/etc/OpenCL/vendors/nvidia.icd

The wrapper was also tested with local symlinks for libnvidia-opencl.so.1 and libOpenCL.so.1, but behavior under Proton did not change.

Why this looks like a Proton or pressure-vessel issue

• The same Windows binary works under local Wine with the same prefix.
• Under Proton, the process gets into Wine builtin OpenCL but never gets past platform enumeration.
• The process exits with code 0, which looks more like a failed enumeration path than a hard crash.
• The host OpenCL stack is present and works outside Proton.

Request

Please investigate why Wine builtin OpenCL under Proton Hotfix plus pressure-vessel fails to enumerate the host NVIDIA OpenCL platform in this setup even though the same binary and prefix work under local host Wine.

If this belongs in steam-runtime rather than Proton, please advise which specific component is responsible.

This may be related to Proton issue [#7537](/issue/ValveSoftware/Proton/7537), which also reports that OpenCL-dependent applications work in vanilla Wine but fail under Proton.