Peter Urbanec winehq.org@urbanec.net writes:
+static BOOL load_funcs(void *handle) +{ +#define LOAD_FUNCPTR(f) if((p##f = (void*)wine_dlsym(handle, #f, NULL, 0)) == NULL) \
- { ERR("Can not find " #f "\n"); return FALSE; } else { TRACE("Loaded function " #f "\n"); };
- /* Platform API */
- LOAD_FUNCPTR(clGetPlatformIDs)
- LOAD_FUNCPTR(clGetPlatformInfo)
- /* Device APIs */
- LOAD_FUNCPTR(clGetDeviceIDs)
- LOAD_FUNCPTR(clGetDeviceInfo)
Why are you loading everything dynamically instead of simply linking to it?
On 30/11/10 21:15, Alexandre Julliard wrote:
Why are you loading everything dynamically instead of simply linking to it?
Couple of reasons. First, a machine may or may not have an OpenCL implementation installed and it may or may not have the required hardware. Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime.
Peter Urbanec winehq.org@urbanec.net writes:
Couple of reasons. First, a machine may or may not have an OpenCL implementation installed and it may or may not have the required hardware.
That's not necessary, the dll will fail to load either way.
Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime.
How is that going to work?
On 01/12/10 22:47, Alexandre Julliard wrote:
Peter Urbanecwinehq.org@urbanec.net writes:
Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime.
How is that going to work?
OpenCL 1.1 removed the clSetCommandQueueProperty API, which means that it's probably no longer going to be exported from the OpenCL 1.1 .so file. On the other hand, OpenCL 1.1 introduces a number of new APIs, such as SubBuffers and BufferRects that won't be in the OpenCL 1.0 .so file.
I have no idea how the various vendors will deal with these changes, so my strategy was to implement a dynamic solution.
The idea being that I can figure out whether an implementation is OpenCL 1.0 or 1.1 compliant, without having to get a list of platform IDs and then query the CL_PLATFORM_VERSION and parse the string.
Perhaps I'm over-engineering this and I should just concentrate on current OpenCL 1.0 functionality and deal with OpenCL 1.1 when it hits mainstream. As it is, the current incarnation of the dynamic loading will fail in more or less the same way as a linked version would.
Would you like me to resubmit the patch with the dynamic loading replaced with a simpler linked version? I guess once we see OpenCL 1.1 implementations in the real world, we can add dynamic loading only for the affected functions, if any.
Best regards,
Peter Urbanec
Peter Urbanec winehq.org@urbanec.net writes:
Would you like me to resubmit the patch with the dynamic loading replaced with a simpler linked version? I guess once we see OpenCL 1.1 implementations in the real world, we can add dynamic loading only for the affected functions, if any.
That would be better, yes.
-
Alexandre Julliard -
Peter Urbanec