openCl setup

Started by
15 comments, last by fir 10 years, 3 months ago

I am not sure if this question is aproppriate

i would like to do some playing with OpenCl code but i got a

limited internet connection and cannot download SDK (which is to big)

I found OpenCl.dll (1.0) in my windows system folder and i think

maybe i could use it with runtime dll linking (without header or

import lib) but also I am somewhat nexperienced in some fields

and I am afraid that it will take in my current situation state

a couple of days ( reading etc)

So i decided to ask maybe someone could help me with that by

providing some opencl setup code i could use with runtime linking?

If no i will be searching myself if yes it maybe could help me,

so much tnx for help...

Advertisement

This might help:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686944%28v=vs.85%29.aspx

You could use dependency walker to figure out the functions.

http://www.dependencywalker.com/

This is not guaranteed to work though... It would be far better to download the SDK if at all possible.

This might help:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686944%28v=vs.85%29.aspx

You could use dependency walker to figure out the functions.

http://www.dependencywalker.com/

This is not guaranteed to work though... It would be far better to download the SDK if at all possible.

Yesterdai i was starting runtime loading OpenCl.dll and then checked if i can fetch the appriopriate function pointers and it seem to work as far by now. (header i got from khronos page) so maybe it will be working...

(I hope so - other way it would be if someone got uploaded the headers and lib from the sdk as a small download i found the info that visualstudio like .lib from the sdk can be probably converted with mingw's reimp tool into mingw .a import library)

But maybe dynamic loading would suffice - hope so, I will see

tnx for answer

The basic OpenCL library is just a wrapper around the ICD (Installable Client Loader) which allows you to select OpenCL devices at runtime, which is a huge advantage. It doesn't provide any functionality by itself, and you generally should not link directly to an OpenCL implementation, even if it seems to work right. On Windows however, the distinction is rather blurred, as vendors tend to bundle the ICD within their DLL's, with the end result that it just works either way, so there's no harm in that case.

You don't need an SDK to work with OpenCL, the runtime will do. Intel provides one separately, I think. Then you grab the headers from the Khronos registry (they may be bundled with the runtime, though more likely with the SDK) and you're good to go.

Also note that OpenCL 1.0 is rather obsolete, essentially everyone has moved to 1.1 and most consumer products (except NVIDIA, of course) support 1.2, with 2.0 being in the works. So it might be worthwhile upgrading either way.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

i began to fetch some opencl calls from some net resources

9this is somewhat experimental sec becaose i hed not mouch

time to read


int main(int argc, char **argv)
{
 
  SetupDllFunctions();
 
 
 cl_platform_id platform_id = 0;
 
 int retval = clGetPlatformIDs_(1, &platform_id, NULL);
 if(retval == CL_SUCCESS ) printf("clGetPlatformIDs success") ;
 
  cl_device_id device_id = 0;
 
  int ret = clGetDeviceIDs_( platform_id, CL_DEVICE_TYPE_GPU, 1, &device_id, NULL );
 
  if(ret == CL_SUCCESS) printf("get device id success ") ;
 
 if(ret == CL_INVALID_PLATFORM) printf("CL_INVALID_PLATFORM") ;
 if(ret == CL_INVALID_DEVICE_TYPE ) printf("CL_INVALID_DEVICE_TYPE ") ;
 if(ret == CL_INVALID_VALUE ) printf("CL_INVALID_VALUE ") ;
 if(ret == CL_DEVICE_NOT_FOUND ) printf("CL_DEVICE_NOT_FOUND ") ;
 
 cl_context context = clCreateContextFromType_(NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &ret);
 if(ret == CL_SUCCESS) printf("context success ") ;
 
cl_command_queue queue = clCreateCommandQueue_(context, device_id, 0, &ret);
 if(ret == CL_SUCCESS) printf("queue success ") ;
 
 
 
 
 char* kernel_src[2] = { "__kernel void SAXPY (__global float* x, __global float* y, float a) { const int i = get_global_id (0); y [i] += a * x [i]; } ", 0};
 
 
 cl_program program = clCreateProgramWithSource_(context, 1, kernel_src, NULL, &ret);
 if(ret == CL_SUCCESS) printf("create program success ") ;
 if(ret == CL_INVALID_CONTEXT )     printf("CL_INVALID_CONTEXT ") ;
 if(ret == CL_INVALID_VALUE )       printf("CL_INVALID_VALUE ") ;
 if(ret == CL_OUT_OF_HOST_MEMORY  ) printf("CL_OUT_OF_HOST_MEMORY ") ;
 
 
 
  return 0;
}

and the outcome here is

clGetPlatformIDs successget device id success context success queue success CL_INVALID_CONTEXT
in the other words platform device context queue seem to be ok, then create program fail
- coul someone help with that?
(god damd how i hate this kind of pseudo programming when you take a loose knot of api calls and you checking if this s**t will work or not - this is more pseudo than programming, unlogical aggrieviating s**t- me head aches as usual when doing such kind of sht)

What are those API calls? Why are you not linking directly to the library using the provided headers, but loading it dynamically? You're introducing another point of failure. The error as I see it does not make sense, the context is clearly valid so clearly something is wrong with clCreateProgramWithSource_. Also try to print out information about the platform and device, and try on a CPU device if you have one.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

What are those API calls? Why are you not linking directly to the library using the provided headers, but loading it dynamically? You're introducing another point of failure. The error as I see it does not make sense, the context is clearly valid so clearly something is wrong with clCreateProgramWithSource_. Also try to print out information about the platform and device, and try on a CPU device if you have one.

well i said in the first post - I cannot download sdk ( i could only download small files ) so i just decided to use LoadLibrary on my OpenCl.dll which resides in windows/system32

clCreateProgramWithSource_ = GetProcAddress(hOpencl, "clCreateProgramWithSource");
Header i take from khronos page, it defines function names
so in my own pointers i added _ to avoid the conflict
context is raported to be good but i do not know if the clcreateprogramwithsource do not need some special
preseting of other api calls or something :/

well i said in the first post - I cannot download sdk ( i could only download small files ) so i just decided to use LoadLibrary on my OpenCl.dll which resides in windows/system32

clCreateProgramWithSource_ = GetProcAddress(hOpencl, "clCreateProgramWithSource");

Header i take from khronos page, it defines function names
so in my own pointers i added _ to avoid the conflict

context is raported to be good but i do not know if the clcreateprogramwithsource do not need some special
preseting of other api calls or something :/

I'm saying you do not need to do all that funky LoadLibrary stuff even without an SDK. Just link to your DLL using -lOpenCL, and use the Khronos headers. In any case I don't think it will do a difference. Where did you get this DLL? Where did it come from? Does it have any version information? What platform do you get with your clGetPlatformIDs call? OpenCL works on the basis of vendors providing implementations, there is no one OpenCL.dll that will enable ultimate access to every GPU ever designed, you need an OpenCL driver (standalone for CPU's, and generally built into graphics drivers for GPU's) and its DLL interface (provided by the vendor) which is then registered with the ICD so that you can select it at runtime without having your users link to any particular DLL.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”


well i said in the first post - I cannot download sdk ( i could only download small files ) so i just decided to use LoadLibrary on my OpenCl.dll which resides in windows/system32

clCreateProgramWithSource_ = GetProcAddress(hOpencl, "clCreateProgramWithSource");

Header i take from khronos page, it defines function names
so in my own pointers i added _ to avoid the conflict

context is raported to be good but i do not know if the clcreateprogramwithsource do not need some special
preseting of other api calls or something :/

I'm saying you do not need to do all that funky LoadLibrary stuff even without an SDK. Just link to your DLL using -lOpenCL, and use the Khronos headers. In any case I don't think it will do a difference. Where did you get this DLL? Where did it come from? Does it have any version information? What platform do you get with your clGetPlatformIDs call? OpenCL works on the basis of vendors providing implementations, there is no one OpenCL.dll that will enable ultimate access to every GPU ever designed, you need an OpenCL driver (standalone for CPU's, and generally built into graphics drivers for GPU's) and its DLL interface (provided by the vendor) which is then registered with the ICD so that you can select it at runtime without having your users link to any particular DLL.

I think i would need mingw import library (opencl.a or something) if i just use -lOpenCL i got

.\..\mingw32\bin\ld.exe: cannot find -lOpenCL
as to this dll
OpenCL.dll
"Khronos OpenCL ICD"
1.0.0.0
Copyright © The Khronos Group Inc 2010
dont know from where it comes from maybe my gt610 gpu driver instalation
GPU-z program gives me the information that OpenCL
is supported here on my machine
Supported Version: full
Supported Profile: OpenCL 1.1 CUDA
i do not know if this dll supports open cl 1.1 but the header
i get (i use them for types) i take 1.1 - think this dynamic loading is probably ok, but i do not know how to call, got not
yet so much time to search and read

If GPU-Z is finding an OpenCL platform then it's working. And, no, a .dll is fine for linking. You might need to tell MinGW to search for it though, I'm not sure it searches System32 by default. Try passing -LC:\Windows\System32 or something like that to the linker (or copy the DLL in your project folder). Loading the entry points of every function manually is stupid since the header already does it for you automatically, you just need to set the linker up right.

As for the problem with the invalid context, I'm not sure. I've never used an NVIDIA device before, and NVIDIA is known for doing strange things with its OpenCL driver. I suggest trying to acquire the context differently, by not using clCreateContextFromType_ but instead clCreateContext (which takes a device ID). Also maybe try the CPU device, if NVIDIA provides one (use CL_DEVICE_TYPE_CPU).

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

This topic is closed to new replies.

Advertisement