Open jfitz-adobe opened 1 year 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.
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?
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?
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!
@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.
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
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: