[PATCH v3 1/3] opencl: Add OpenCL 1.0 function pointer loader.

[Nakarin Khankham]

On 12/03/2019 11:28, Roderick Colenbrander wrote:
> Hi Nakarin,
> 
> Thanks for sharing your opencl work. I shared a brief reply earlier as
> well, though I must admit I was brief and not very clear (we just had
> a baby and was super tired).
> 
> Anyway my main concern is more about how our current OpenCL
> implementation works and its maintainability. I'm not too familiar,
> with opencl, but as a Khronos standard it has a lot of similarities
> with OpenGL and Vulkan on which I worked on the Wine implementations.
> 
> The current OpenCL 1.0 implementation in Wine was probably
> handwritten. I'm not sure if there was a "cl.xml" back then from which
> the code could have been generated, but at least there is now. That is
> what we do for OpenGL and Vulkan as well. The bulk of the code is just
> autogenerated (make_vulkan or make_opengl), while the few calls which
> need special handling are implemented by hand. Any of these scripts
> can probably modified easily, vulkan probably a tad easier.
> 
> This is very handy as we can re-run the scripts and we get the latest
> OpenGL / Vulkan. OpenCL is now at 2.2 and with little work, we would
> have gotten the support. In addition there are a lot of extensions as
> well for which we can then add wrappers too (and deal with
> clGetExtensionFunctionAddress).
> 
> My personal vote would be for OpenCL to be automatically generated.
> Just have the few calls which need manual work in "opencl.c" and
> anything else similar to opengl/vulkan in like "opencl_thunks.c".
> 
> Long-term we should maybe even consider to move to the OpenCL ICD
> standards. If you are not familiar opencl dll is really a loader for
> the vendor supplied opencl Installable Client Driver. We would maybe
> have a wineopencl.dll and opencl.dll. Since OpenCL is not that
> commonly used in consumer applications, it is probably not worth any
> of the effort right now.
> 
> Thanks,
> Roderick
> 

Thank you for the input.

Originally, my goal of this patch is to make OpenCL 1.2 without any
extension available, As there is one Windows program that I use require
it for one of it's function, namely DAZ Studio's cloth simulator, which
require OpenCL 1.2 support on wine side to function, as was in
https://bugs.winehq.org/show_bug.cgi?id=46470

I agree that the OpenCL should be automatically generated, as that seems
to be the best, proper and easy way of update it later when the new
version of OpenCL come out in the future.

But I'm afraid that the auto code generator thingy was beyond my current
coding ability, and both OpenGL and Vulkan auto code generator
(I just look at it recently), one was short but written in language
I known nothing of (perl), and one while was written in language that
I can write a very small beginner level program out of it (python),
was too long and complex for current me to study it with my little freetimes
that I have each day (it likely take me month(s) to do it and I was
discourage by that also :<)

For now, I think I'll post this patch somewhere that can be easily found
by people who need it, likely on the appropriate wine bug report comment.

I may revisit this patch in the future tho, as a python exercise by make
a code generator with the help from the one used in winevulkan, and make
the opencl like the way how vulkan-1 and winevulkan is implemented.

Also, congratulation! ^^