Advertisement Jump to content
Sign in to follow this  
fir

openCl setup

This topic is 1827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...

 

 

 

 

Share this post


Link to post
Share on other sites
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.

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)
Edited by fir

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :/

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 


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 

Share this post


Link to post
Share on other sites

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).

Edited by Bacterius

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!