On Sat, Mar 2, 2019 at 10:21 AM Nikolay Sivov nsivov@codeweavers.com wrote:
On 3/2/19 8:57 PM, Nakarin Khankham wrote:
On 02/03/2019 19:18, Nikolay Sivov wrote:
On 3/2/19 2:02 PM, Khral Steelforge wrote:
Signed-off-by: Nakarin Khankham garuda2550@gmail.com
dlls/opencl/opencl.c | 188 ++++++++++++++++++++++++++++++++++++++++ dlls/opencl/opencl.spec | 10 +++ 2 files changed, 198 insertions(+)
diff --git a/dlls/opencl/opencl.c b/dlls/opencl/opencl.c index 2d145bf25c..ec046a669e 100644 --- a/dlls/opencl/opencl.c +++ b/dlls/opencl/opencl.c @@ -295,6 +295,21 @@ cl_mem WINAPI wine_clCreateBuffer(cl_context context, cl_mem_flags flags, size_t return ret; } +cl_mem WINAPI wine_clCreateSubBuffer(cl_mem buffer, cl_mem_flags flags,
cl_buffer_create_type buffer_create_type, const void * buffer_create_info, cl_int * errcode_ret)+{ +#ifdef CL_VERSION_1_1
- cl_mem ret;
- TRACE("\n");
- ret = clCreateSubBuffer(buffer, flags, buffer_create_type, buffer_create_info, errcode_ret);
- return ret;
+#else
- FIXME("stub\n");
- *errcode_ret = CL_SUCCESS;
- return NULL;
+#endif +}
Looks like this should be accessed dynamically. How capabilities are reported for OpenCL, e.g. if I've built this with 1.1+ dev library support, and run it on 1.0 host what should happen when application sees 1.1 export?
Thankyou for the feedback.
By dynamically access the functions, you mean use dlopen and dlsym function? (in wine case, wine_dlopen and wine_dlsym?)
something like this?
... #define SONAME_LIBOPENCL "libOpenCL.so.1" /* this might be better auto generate by the configure script */ static void* opencl_handle = NULL; static cl_mem (*p_clCreateSubBuffer)(cl_mem buffer, cl_mem_flags flags, cl_buffer_create_type buffer_create_type, const void * buffer_create_info, cl_int * errcode_ret); ... cl_mem WINAPI wine_clCreateSubBuffer(cl_mem buffer, cl_mem_flags flags, cl_buffer_create_type buffer_create_type, const void * buffer_create_info, cl_int * errcode_ret) { #ifdef CL_VERSION_1_1 cl_mem ret; char error[200]; TRACE("\n");
if(!opencl_handle) { opencl_handle = wine_dlopen(SONAME_LIBOPENCL, RTLD_NOW, error, sizeof(error)); if (opencl_handle == NULL) { ERR( "Failed to load OpenCL: %s\n", error ); return 0; } }#define LOAD_FUNCPTR(f) do if (!(p_##f = wine_dlsym( opencl_handle, #f, error, sizeof(error) ))) \ { \ ERR( "%s not found in %s (%s), disabling.\n", #f, SONAME_LIBOPENCL, error ); \ goto failed; \ } while(0)
LOAD_FUNCPTR(clCreateSubBuffer);#undef LOAD_FUNCPTR
ret = p_clCreateSubBuffer(buffer, flags, buffer_create_type, buffer_create_info, errcode_ret); return ret;failed: wine_dlclose( opencl_handle, NULL, 0 ); opencl_handle = NULL; return 0;
#else FIXME("stub\n"); *errcode_ret = CL_SUCCESS; return NULL; #endif }
If yes, then I think I can improve this patch with guidance from examples in wine's source code.
Yes, something like this, except that you can have a single ifdef block to build 1.1 stuff, and then get all function pointers at once, leaving empty exported function bodies in case 1.1 headers where not available at build time.
For example you can look at odbc32/proxyodbc.c.
Ideally, if it's possible, it could be generated from some spec function lists, and then simply iterated over to bind them. See include/wine/wgl_driver.h, and related part in init_opengl() in winex11.drv.
Continuing a bit on this note. Currently whatever scripts have been used to generate opencl, are not in Wine, which is bad and makes updating hard (e.g. adding new extensions etcetera). It should be part of Wine.
The other issue is that if I'm truly honest the architecture of our opencl DLL is not correct (not sure if looking back it should have been merged the way it was). So far the opencl library focused on just the opencl bits, but opencl allows for interop with OpenGL, Direct3D and Vulkan. Just a simple passthrough like now is not sufficient for that I think. Not sure how we should do it though. We could follow the ICD standard for it,.. not sure what it would buy though, but we may have to go that way for interop.