[PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
winehq.org at urbanec.net
Wed Dec 1 06:50:37 CST 2010
On 01/12/10 22:47, Alexandre Julliard wrote:
> Peter Urbanec<winehq.org at 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.
More information about the wine-devel