The procedure entry point clCreateFromGLBuffer could not be located in the dynamic link library OpenCL.dll

[BlohoJo]

Using MESA 21.3.5 MSVC.

Trying to use DaVinci Resolve 15 on GPU-less workstation, it uses either CUDA or OpenCL.

It starts and gives expected "Can't find OpenCL GPU" message when run.

I copied all dll files from mesa3d-21.3.5-release-msvc\x64 into Resolve directory.

Now when Resolve 15 is started, it says, "The procedure entry point clCreateFromGLBuffer could not be located in the dynamic link library OpenCL.dll."

Just to experiment, I renamed OpenCL.dll to OpenCL.dll.bak and MesaOpenCL.dll to OpenCL.dll. Now, it gives the message, "The procedure entry point clEnqueueBarrier could not be located in the dynamic link library OpenCL.dll."

Are there some environment variables I might be missing, or other files I'm maybe missing from other packages somewhere? I tried putting in vulkan-1.dll from VulkanRT-1.2.198.1-Components\x64 but it made no difference.

Also, the message still comes up if ONLY OpenCL.dll and/or MesaOpenCL.dll is in the application directory.

I tried 22.0.0-rc1 and it had no effect on the above.

[BlohoJo]

An important note I forgot:

I have installed "Intel CPU Runtime for OpenCL Applications 18.1 for Windows OS (64bit or 32bit)" - opencl_runtime_18.1_x64_setup.msi

Should I maybe uninstall that?

CPU is 16 core Intel Xeon / Coffee Lake / E-2288G CPU @ 3.70GHz

[BlohoJo]

I guess I do need the above runtime, because otherwise there is no opencl.dll in the Windows system directories. I tried the other Intel OpenCL installer, but that appears to be for Intel CPU's with onboard Graphics. The OpenCL test/benchmark program ViennaCLBench fails to run with that, but runs with the runtime that I linked in the post above this one.

The MESA docs say that it should be completely overriding all OpenCL calls anyway. I can't test MESA with ViennaCLBench because it's a 32 bit program, and the x86 builds of clover have failed so far in MESA. ;)

Here's Resolve 15.3.1 free/trial if you want to test it.

[pal1000]

Just to experiment, I renamed OpenCL.dll to OpenCL.dll.bak and MesaOpenCL.dll to OpenCL.dll.

That's a bad idea because MesaOpenCL.dll is an ICD that needs to be loaded by official Khronos OpenCL runtime.

You can register MesaOpenCL.dll with Khronos OpenCL runtime by adding it in registry like this Don't forget to remove Mesa DLLs from program folder otherwise it won't pick it up.

[BlohoJo]

Hey! Thanks for the reply! :)

Unfortunately, I couldn't get it to work. Resolve now starts like there is no OpenCL on the system, and gives the message, ""DaVinci Resolve could not find any OpenCL capable GPUs."

What files should not be in the program directory?

Here's what I've got so far:

Made directory C:\Program Files\MESA

Copied in the following:

MesaOpenCL.dll OpenCL.dll clon12compiler.dll pipe_swrast.dll

Created Dword32 entry C:\Program Files\MESA\MesaOpenCL.dll under key HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors, set to 0. Like your screenshot I also have an entry for intelocl64.dll.

In the Resolve application directory, I have:

libgallium_wgl.dll libglapi.dll opengl32.dll vulkan-1.dll

All MESA files from 21.3.5 MSVC release. Vulkan-1.dll from VulkanRT-1.2.198.1-Components.zip.

I checked resolve.exe with x64dbg and created a log file. Looking at the file, I can see that it loads all four MESA OpenGL files listed above from the application directory. It doesn't load opengl32.dll from the Windows System directory.

With OpenCL, it loads:

C:\Windows\System32\OpenCL.dll C:\Program Files (x86)\Common Files\Intel\OpenCL\windows\compiler\lib\intel64_win\intelocl64.dll C:\Program Files (x86)\Common Files\Intel\OpenCL\windows\compiler\lib\intel64_win\task_executor64.dll C:\Program Files (x86)\Common Files\Intel\OpenCL\windows\compiler\lib\intel64_win\cpu_device64.dll C:\Program Files\MESA\MesaOpenCL.dll

That's everything I noticed. MesaOpenCL.dll does throw numerous exceptions in the log file.

Here's the entire x64dbg log file: https://pastebin.com/bWPY9aaW

Resolve does appear to be looking for a hardware GPU, so maybe it just simply won't work with MESA. Or it could be something stupid like a file needing to be named something specific. I remember when I was trying to get Topaz applications to run with MESA and had just about given up, thinking it wasn't possible, and I have no idea what made me think to try this, but I made a second copy of MESA's opengl32.dll in the application directory and named it opengl32sw.dll, and that actually worked. I was shocked when I saw the application run. I discovered that it would only work if both opengl32.dll (MESA) and opengl32sw.dll (duplicate copy of MESA opengl32.dll) were present in the application directory. Delete one, and it no longer works. There was NOTHING from looking at any debugger, logs, or otherwise to lead anyone to think that that would be what makes it work. So it's possible there's something like that going on here. (I have no idea, just guessing.)

[pal1000]

Copy libgallium_wgl.dll and libglapi.dll in C:\Program Files\MESA and then remove those 4 files from Dvinci Resolve folder. If this still doesn't work we are kind of screwed.

[BlohoJo]

It didn't work. Oh well, thanks for trying! :\

It gives this error:

If I click "Update Configuration" it shows this:

I believe that's the problem. It should list an entry in there for the "GPU" which is the Intel CPU runtime for OpenCL, like it shows here in ViennaCLBench:

I mean, MESA shouldn't really be necessary, since the Intel drivers I have installed are supposed to be a complete software rendering runtime. So it must mean Resolve 15 is coded in such a way as to need to see a physical GPU card. The reason I tried at all is that I've heard of people running Resolve 15 on Linux using MESA, so I thought it should work for Windows, since OpenCL is now part of the Windows build here (at least for x64 so far). It must be that the Linux version of Resolve is coded without the limitation of needing a physical GPU. I suppose I could try older versions of Resolve, but I think I've spent too much time on this so far!

Thanks again for the replies. :)

[BlohoJo]

I tried running this:

http://wiki.luxcorerender.org/LuxMark_v3 https://github.com/LuxCoreRender/LuxMark/releases/download/luxmark_v3.1/luxmark-windows64-v3.1.zip

It crashed.

I then removed the registry entry of C:\Program Files\MESA\MesaOpenCL.dll under key HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors.

After doing that, LuxMark now runs.

So I guess Resolve is hard coded not to use a software renderer for OpenCL.

LuxMark should work with the MESA version of OpenCL though, shouldn't it?     Here's the x64dbg log of the LuxMark crash with the MESA registry key in place (it loops endlessly at the end): https://pastebin.com/dYwcbBP6

Faulting application name: luxmark.exe, version: 0.0.0.0, time stamp: 0x55e59579
Faulting module name: MSVCR120.dll, version: 12.0.40660.0, time stamp: 0x577e0cc7
Exception code: 0x40000015
Fault offset: 0x00000000000748a6
Faulting process id: 0x4220
Faulting application start time: 0x01d81fb22e7f7654
Faulting application path: E:\luxmark-windows64-v3.1\LuxMark-v3.1\luxmark.exe
Faulting module path: C:\Windows\system32\MSVCR120.dll
Report Id: 6d10ad07-8ba5-11ec-a7fb-0050560334cc

    And here's the log of LuxMark running with the MESA registry key removed: https://pastebin.com/kZQWkDbN

    Oh s**t, I probably should have mentioned this is Windows Server 2008 R2 (equivalent to Windows 7). MESA isn't now Windows 10/11 only, is it?

[pal1000]

So it must mean Resolve 15 is coded in such a way as to need to see a physical GPU card.

Precisely, it demands a CL GPU type device, see pal1000/save-legacy-intel-graphics#4. It might work with Mesa clover (MesaOpenCL.dll) or CLonD3D12. You don't seam to have much luck with former and judging by this

Oh s**t, I probably should have mentioned this is Windows Server 2008 R2 (equivalent to Windows 7).

you are way bellow the requirements for latter.

I tested ViennaCLBench but it's not relevant to this issue because it's a 32-bit program so it can't use Mesa clover and it also uses CL CPU type devices if available.

[pal1000]

I tested LuxMark and I got the same crash you reported. CLonD3D12 crashes too but at least it let us in enough so we can disable it from right pane if we are fast enough. You should report crashes like this upstream for better visibility.

[BlohoJo]

I keep trying new MESA versions, including the latest 22 r2, and so far I have not found a single thing working with OpenCL. Same crash on Luxmark, etc. The release notes seem to indicate changes and such for clover... is ANYTHING supposed to be working for OpenCL? If not, what is the point of these non working builds? Not trying to sound insulting or anything... just confused.

[pal1000]

Well, clond3d12 is also available for Windows 10 and 11 and it works even without a D3D12 graphics driver by using the CPU. I may give up on clover if I keep getting reports that is so broken.

[BlohoJo]

At this point I'm just trying Luxmark with new releases to see if it will start.

Still crashes with mesa3d-22.1.0-release-msvc. :disappointed:

MESA folder contains MesaOpenCL.dll, libgallium_wgl.dll, and libglapi.dll. Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors has 32 bit Dword C:\Program Files\MESA\MesaOpenCL.dll in it. Luxmark crashes. Delete that Dword, and it runs with Intel CPU OpenCL drivers (intelocl64.dll is in above registry key).

[TherealGenius]

also please notice this

The OpenCL CPU runtimes will be installed to the following directory: C:\Program Files (x86)\Common Files\Intel\Shared Libraries\

Known Issues and Limitations A known-issue in the installer of previous version of Intel® OpenCL driver for Intel® Graphics for Windows that removes one registray key, so the OpenCL application will fail to run on Intel CPU processor.

Workaround: this issue can be fixed with the method below.

Manually update the registry key: run "Registry Editor" program go to for x32 HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors

for x64 HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Khronos\OpenCL\Vendors

add a new key with following key-value pair:

for x64 "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\intelocl64.dll"=dword:0 this file dont showng up at inside regedit or the folder intelocl64_emu.dll

for x32 "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\ia32\intelocl32.dll"=dword:0 "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\ia32\intelocl32_emu.dll"=dword:0

the file named C:\Windows\system32\MSVCR120.dll its from the Microsoft Visual C++ Redistributable

that file is for Visual C++ Redistributable Packages for Visual Studio 2013

Visual Studio 2015, 2017, 2019, and 2022 docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

Architecture Link ARM64 https://aka.ms/vs/17/release/vc_redist.arm64.exe Permalink for latest supported ARM64 version X86 https://aka.ms/vs/17/release/vc_redist.x86.exe Permalink for latest supported x86 version X64 https://aka.ms/vs/17/release/vc_redist.x64.exe Permalink for latest supported x64 version.

                 Notes
                 The X64 Redistributable package contains both ARM64 and X64 binaries. 
                 This package makes it easy to install required Visual C++ ARM64 binaries when the X64 Redistributable is 
                 installed on an ARM64 device

also notice The current installed version number is stored in the HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\VisualStudio\14.0\VC\Runtimes{x86|x64|ARM} key.

every visual studio got it version number for the

The version number is 14.0 for Visual Studio 2015, 2017, 2019, and 2022 because the latest Redistributable is binary compatible with previous versions back to 2015

[BlohoJo]

Yeah, that's fine, I have that registry key and OpenCL for Intel CPU works fine. It's the MESA Clover OpenCL GPU software emulation that is not working... yet. Hopefully it will, someday? :p

[BlohoJo]

The upstream was closed with "Closing now that Clover's probably going away."

Not sure if that means that Windows will not support OpenCL at all for the future, or if Clover will be replaced with something else.

[pal1000]

Not sure if that means that Windows will not support OpenCL at all for the future

Windows has CLonD3D12 driver but it may have stopped working with switch to LLVM/Clang 15.

or if Clover will be replaced with something else.

It's being replaced by Rusticl, but this new driver doesn't build for Windows yet.

[BlohoJo]

As usual, please forgive my ignorance...

How does one go about configuring the system for openclon12 / CLonD3D12?

I tried the simple "copy all dll's from the latest release into the application directory," but that didn't work for Luxmark. I tried both MSVC and MingW.

[pal1000]

Using CLonD3D12 works the same way it worked with clover ICD (MesaOpenCL.dll). CLonD3D12 ICD name is openclon12.dll.

[BlohoJo]

What other files should be in the directory that contains openclon12.dll?

[pal1000]

Registering OpenCL or Vulkan drivers in general doesn't involve copying files over to program folder at all, instead it works by writing to registry or setting environment variables that point to driver full path. I already gave you an example with registry here. Also don't forget CLonD3D12 requires Windows 10.0.19041.488 or newer.

[BlohoJo]

I understand that, what I am asking is, what files other than openclon12.dll need to be in the driver full path folder? openclon12.dll is under 2 MB so there must be other files that need to be in the driver path folder, right? :confused:

[pal1000]

I recommend you to just extract mesa-dist-win release package somewhere and then the paths to CLonD3D12 driver would be <path-to-mesa-dist-win>\bin\x64\openclon12.dll and <path-to-mesa-dist-win>\bin\x86\openclon12.dll respectively.

For Vulkan and OpenCL drivers you don't have to copy any files to program directory. OpenCL ICD loader and Vulkan runtime respectively handle finding drivers' depending DLLs for us.

To satisfy your curiosity openclon12.dll depends on dxil.dll, clon12compiler.dll and on x64 only, WinPixEventRuntime.dll.

[BlohoJo]

OK, thanks very much for the clarification.

Again (sorry for so many basic questions), does the Vulcan runtime need to be in the driver path folder along with MESA, or does the Vulcan runtime go in its own driver path? (Or in the Windows\System32 directory)?

Remember, I'm attempting to get a MESA to run as GPU MESA, on a system that does not have a GPU, which I'm assuming should be possible in the same way that OpenGL is able to run OpenGL dependent applications on a system without a GPU (i.e., a VPS).

[pal1000]

Vulkan runtime is packaged an excusable installer. Just run it as it's unpacked in Windows\System32.

[BlohoJo]

Hello again and Happy Holidays!

I finally had time to try openclon12.dll. It didn't work, Luxmark still crashes, but it looks a bit different now. It appears to crash at the point where it would start drawing onscreen. Event log just shows Luxmark crashing itself (luxmark.exe), so that isn't really useful.

Here's what I did (Windows 10 x64 2004 final build 19041.1415):

1 - System path environment variable added C:\Program Files\MESA\

2 - Place all files from mesa3d-22.3.1-release-msvc.7z\x64\ into C:\Program Files\MESA\. (Also tried with mesa3d-22.3.1-release-mingw.7z\x64\, this had no effect.)

3 - Create zero value DWORD registry entry openclon12.dll under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors.

4 - Install Vulkan runtime VulkanRT-1.3.236.0-Installer.7z. (Also tried manually copy + pasting files from VulkanRT-1.3.236.0-Components.zip into C:\Windows\System32 and C:\Windows\SysWOW64, this had no effect.)

I think that should be everything?

So this is what happens when I try to run Luxmark:

Unfortunately, since it crashes nearly right away, I cannot scroll down the log text on the bottom, or export it since the application is in a crashed state.

Does this require a GPU to work? The Vulkan runtime is for a GPU, and this is a system with no GPU. If it does need a GPU, then I wonder what is the point, as I thought this was supposed to be a GPU software renderer for OpenCL, unless I am misunderstanding something. (Should I be doing anything with Swiftshader?)

[pal1000]

I got crash with Luxmark 3.1 and CLonD3D12 as well so it's not just you. Try collecting a call stack (MSVC) or backtrace (MinGW). Help yourself with debug packages. Report the crash to Mesa3D CLC or CLonnD3D12 ICD depending on module crashing clon12compiler.dll or openclon12.dll respectively.

[BlohoJo]

I tried the latest MESA version 24 in LuxMark and it no longer crashes, but it still fails to use MESA and gives a "No OpenCL device selected or available" message in the log:

MSVC or MingW behaves the same.

It appears that there is a bug in MESA 24.0.0 on how WARP is exposed to the system, as it appears as device type UNKNOWN. I'm not sure if this is a problem with openclon12.dll or clon12compiler.dll.

OpenCLon12 was changed in version 23.0.0 to expose WARP as a CPU device, so unless they implement an environment variable that can select how WARP is exposed to the system (as either CPU or GPU), then I'm still out of luck, as I need it to be exposed as GPU. :(

[BlohoJo]

I got OpenCL on MESA 24.0.0 to work! But, just MSVC... MINGW crashes LuxMark.

If I select "Benchmark (OpenCL GPUs)" or "Benchmark "OpenCL CPUs", I get the "RUNTIME ERROR: No OpenCL device selected or available" message in the log. This is due to WARP being exposed as device type UNKNOWN.

BUT, if I select only MESA ("Microsoft Basic Render Driver") on the right, and select "Benchmark (OpenCL selected devices only)" from the "Mode" menu, it works! (I also tried it with renaming the directory for the Intel OpenCL CPU driver to make sure that it can't be used at all.) I extracted the x64 directory from mesa3d-24.0.0-release-msvc.7z to C:\Program Files\MESA, and then made sure openclon12.dll was specified in the Windows Registry as a 32 bit DWORD with a 0 value in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors and Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Khronos\OpenCL\Vendors.

It is slower than the Intel driver, but it is complete and renders more like a GPU without any diffusion dithering.

https://pastebin.com/BMJfUBjU (line 85 and forward)

It's not going to be usable however with any applications that expect either an OpenCL CPU or GPU device due to the issue with WARP being exposed as device type UNKNOWN.

It might actually work for Resolve and other applications that only allow OpenCL GPU devices if there was a way to select how WARP is exposed to the system (CPU or GPU) via an environment variable.

:(

I wonder if there is a way to compile MESA or OpenCLon12 so that it is seen as a GPU?

[pal1000]

Try 24.0.3. I updated CLonD3D12 ICD to include fix for microsoft/OpenCLOn12#58