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! ^^