As far as I always understood, one OpenCL application should be able to be used on any OpenCL capable piece of hardware out there, just in the same way that OpenGL can be used on any capable hardware out there without having to write a specific API for that piece of hardware.

What I omitted was that it's even platform independent. Meaning the one OpenCL application can be used for any GPU or CPU whether they run Windows, Linux, MacOS, Android and a handful of other OSes.

---

If you look at a typical OpenCL application at SETI, it looks something like this:

    <app_version>
        <app_name>setiathome_v8</app_name>
        <version_num>822</version_num>
        <platform>windows_intelx86</platform>
        <api_version>7.5.0</api_version>
        <avg_ncpus>0.04</avg_ncpus>
        <max_ncpus>0.2</max_ncpus>
        <plan_class>opencl_nvidia_SoG</plan_class>
        	<cmdline></cmdline>	
	<coproc>
            <type>CUDA</type>
            <count>1</count>
        </coproc>
        <file_ref>
            <file_name>MB8_win_x86_SSE3_OpenCL_NV_SoG_r3557.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3-3-4_x86.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>MultiBeam_Kernels_r3557.cl</file_name>
        </file_ref>
        <file_ref>
            <file_name>mb_cmdline_win_x86_SSE3_OpenCL_NV_SoG.txt</file_name>
            <open_name>mb_cmdline.txt</open_name>
        </file_ref>
    </app_version>

The 'main program' is MB8_win_x86_SSE3_OpenCL_NV_SoG_r3557.exe - that's, in this case, a 32-bit Windows executable, and it runs on the CPU. No way is that going to run under Linux or Mac.

The OpenCL bit is MultiBeam_Kernels_r3557.cl - it's only that part which is fully platform-independent. It's written in an intermediate-level code, but expressed in plain text. You can open it with a text editor, and see that it starts with Raistmer's cross-platform notes:

//R: here kernels for SETI MultiBeam OpenCL build will be located
// This version is using fraction(a * b * b) = fraction((_a + fa) (_b + fb) ^ 2) for enhancing the precision
#define M_2PI              6.28318530717958647692f //R: it's single precision constant here !
//#if USE_OPENCL_NV || USE_OPENCL_HD5xxx || USE_OPENCL_INTEL
//	#define OCL_REAL_LOCAL 1
//#endif
#if defined(USE_OPENCL_INTEL) || defined (__APPLE__)&&defined(USE_OPENCL_NV)
  #pragma OPENCL FP_CONTRACT OFF
#endif

That code is compiled on the user's local machine (using a compiler application included in the driver runtime support package) to generate binary code tailored to the exact hardware and software target in use.

Einstein embed the OpenCL code into their single-file CPU application, so you can't see the inner workings as clearly as you can at SETI, but it works the same way.

The 'main program' is MB8_win_x86_SSE3_OpenCL_NV_SoG_r3557.exe - that's, in this case, a 32-bit Windows executable, and it runs on the CPU. No way is that going to run under Linux or Mac.

Why not? It's just compiled code. A little trick I learned back when from Jack from Drugdiscovery@Home: did you know that for Unix it doesn't matter what the name of an application is, to make it an executable? You can run a Windows named executable application in Linux (and probably just as well in MacOS) including the .exe extension, as long as you define that it's an executable. On its own MB8_win_x86_SSE3_OpenCL_NV_SoG_r3557.exe is just as any file, but right-click it in Linux and on the Permissions tab check "Allow executing file as a program" and you're done. You can sudo chmod it as well, of course: sudo chmod +x MB8_win_x86_SSE3_OpenCL_NV_SoG_r3557.exe will make that whole file executable under Linux.

As for it won't be able to execute as it does under Windows, all I have said so far is that default applications should be able to run on any OpenCL capable hardware. I think Eric told me once that the base OpenCL applications at Seti are all one and the same application, just renamed to match the plan-class.

The specially built applications for specific hardware may not be able to execute on other hardware. But just generic OpenCL ones should.

---

Yes but...

Any file is just a sequence of bytes: the name is irrelevant, although the windows 'File Type' based on extension saves a lot of time.

But if you run a Windows file anywhere else, you are likely to get the error message "This program requires Microsoft Windows" - because the Windows ecosystem is built around a shared library of Dynamic Link Libraries or DLLs to perform common, shared, functions. If those libraries can't be attached by using the expected system calls, the whole structure falls apart. A program could be contrived to run on the bare hardware, sure - but if it requires to do any system-level operations, like writing files to disk, the chances of it succeeding are vanishingly small.