microsoft / OpenCLOn12

The OpenCL-on-D3D12 mapping layer
MIT License
104 stars 13 forks source link

Is OCL/OGL CompatPack supposed to load on x64? #49

Open jfitz-adobe opened 9 months ago

jfitz-adobe commented 9 months ago

hi @jenatali,

After installing the "OCL/OGL CompatPack" (v2302.1.0) on an Intel x64 machine, I notice that the CompatPack "DLL redirect" (opencl.dll -> OpenCLOn12.dll and opengl32.dll -> OpenGLOn12.dll) is enabled and the mesa-based DLLs (xxxOn12.dll) are loaded on behalf of the Host Application. This creates an "attractive nuisance" for some customers who see CompatPack installed on their Arm64-based systems and then think they also need to also-install it on their x64-based systems. Certain customers then encounter crashes as the mesa-based devices compete for Application attention in untested ways.

Q: Is there a way to enable this CompatPack "DLL redirect" only for Arm64, while disabling it for x64?

See:

// Loaded Modules
//
OpenCL.dll  OpenCL.dll  C:\Windows\System32\OpenCL.dll  N/A Yes Cannot find or open the PDB file.       300 3.00.3.0    6/8/2023 5:09 PM
OpenCLOn12.dll  OpenCLOn12.dll  C:\Program Files\WindowsApps\Microsoft.D3DMappingLayers_2.2302.1.0_x64__8wekyb3d8bbwe\x64\OpenCLOn12.dll    N/A Yes Cannot find or open the PDB file.       303     2/7/2023 5:02 PM
opengl32.dll    opengl32.dll    C:\Windows\System32\opengl32.dll    N/A No  Symbols loaded without source information.  C:\Users\me\AppData\Local\Temp\SymbolCache\opengl32.pdb\b2f628396d16c4de262199a077a6616e1\stripped\opengl32.pdb 62  10.0.19041.2193 (WinBuild.160101.0800)
OpenGLOn12.dll  OpenGLOn12.dll  C:\Program Files\WindowsApps\Microsoft.D3DMappingLayers_2.2302.1.0_x64__8wekyb3d8bbwe\x64\OpenGLOn12.dll    N/A Yes Cannot find or open the PDB file.       275     2/8/2023 4:51 PM
shawnhar commented 9 months ago

This is by design. When the compatibility pack mapping layers are installed on a system that already has an ICD driver implementation provided by an IHV, they will enumerate as an alternative OpenCL device alongside the ICD device (coming after it, so most apps will default to the ICD implementation). This is desirable for some use cases that explicitly want to use mapping layers across all systems. X64 OEMs will not be preinstalling the compatibility pack in the same way that it is for ARM64 systems, however.

jfitz-adobe commented 9 months ago

most apps will default to the ICD implementation

understood. however, our App/x64 sees the alternative OpenCL device as an opportunity to "add more parallelism" to large workloads. we attempt to use it, and then encounter crashes in CLOn12Compiler with certain of our old-timey/wonky shader programs.

X64 OEMs will not be preinstalling the compatibility pack in the same way that it is for ARM64 systems

yes: "preinstalled only for Arm64". however, unlike the ICD drivers, the CompatPack translation layer shows up in the AppStore as "already owned" + "ready to install". and some subset of x64 customers can't resist the urge to click "install"... confounding our QA test matrix.

Q: is it your guidance that if we want to disallow x64 use of alternative OpenCL device from CompatPack translation layer, then our App should filter for cl->PlatformNameString() == "OpenCLOn12" on x64 platform?

shawnhar commented 9 months ago

That sounds like a reasonable filtering approach to me.

In general we'll want to fix any compiler crashes that you are running into, though! Presumably the same problems will also be seen on ARM64 systems. Are you able to share repros for these?

jfitz-adobe commented 9 months ago

ok, understood: "filter for known-unwanted alternative devices". you can consider this issue closed.

we'll open a new issue for CLOn12Compiler/x64 crashes once we hunt up some minidumps. thanks!

MathiasMagnus commented 9 months ago

@jfitz-adobe I would say this is a slippery slope. It will be a long chase of filter runtimes without explicitly having settings exposed to the user (like LuxMark does). OpenCLOn12 is one such runtime which drives devices that may have vendor runtimes installed too. clvk, POCL are two other just to name two which may very well be installed on a system and are similar in essence.

jlewis-austin commented 9 months ago

This PR on the Vulkan side may be relevant, mitigating the filtering burden by allowing ICDs to self-identify as "layered": https://github.com/KhronosGroup/Vulkan-Docs/pull/2121