hwinfo icon indicating copy to clipboard operation
hwinfo copied to clipboard

Make OpenCL an optional dependency

Open diiigle opened this issue 1 year ago • 5 comments

Is there any way to make OpenCL (quite a heavy chunk to the otherwise small and lightweight library) fully optional? I see you have a CMake option to not use it, however git submodules still downloads the whole subtree, even if one doesn't want it.

https://cmake.org/cmake/help/latest/module/FetchContent.html comes to mind.

diiigle avatar Sep 29 '23 16:09 diiigle

Hi, valid point! I'll check the options and will change how OpenCL is added.

lfreist avatar Sep 30 '23 12:09 lfreist

Yes, please. At the moment it does not work correctly at all:

CMake Error at external/miss-opencl/CMakeLists.txt:22 (add_subdirectory):
  The source directory

    /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_hwinfo/hwinfo/work/hwinfo-a1ae945ab784780af5fc166150a6f6612d41e7bf/external/miss-opencl/external/OpenCL

  does not contain a CMakeLists.txt file.


-- Configuring incomplete, errors occurred!

barracuda156 avatar Oct 03 '23 03:10 barracuda156

You need to run git update --init --recursive first. However, building on Mac has some issues atm since I do not have access to a Mac...

lfreist avatar Oct 03 '23 07:10 lfreist

This OpenCL repo does have another downside (for your users) which you might be not aware of:

fatal: clone of 'https://github.com/throwtheswitch/cexception.git' into submodule path 'C:/Users/myname/repositories/my-looongish-repo-name/ext/hwinfo/external/miss-opencl/external/OpenCL/external/OpenCL-CLHPP/external/CMock/vendor/c_exception' failed
Failed to clone 'vendor/c_exception'. Retry scheduled
Cloning into 'C:/Users/myname/repositories/my-looongish-repo-name/ext/hwinfo/external/miss-opencl/external/OpenCL/external/OpenCL-CLHPP/external/CMock/vendor/c_exception'...
fatal: cannot write keep file 'C:/Users/myname/repositories/my-looongish-repo-name/.git/modules/ext/hwinfo/modules/external/miss-opencl/modules/external/OpenCL/modules/headers-cpp/modules/external/CMock/modules/vendor/c_exception/objects/pack/pack-fd8baa50a07a4317443b1e3b5520f09f92fa84cf.keep': Filename too long

The submodules are nested so deep, that some filenames run out of MAX_PATH=260 on Windows. I can't even clone my own repo any more because of that unless I go to C:\tmp\ or something.

Fruit for thought, if OpenCL isn't a bit of an overkill.

Edit: git -c submodule."external/miss-opencl".update=none submodule update --init --recursive seems to be a workaround for now. https://stackoverflow.com/a/52185169

diiigle avatar Oct 12 '23 11:10 diiigle

Yes, OpenCL kind of is an overkill, but for now, I found no other way to retrieve GPU Memory information...

lfreist avatar Oct 13 '23 07:10 lfreist

I would suggest removing GPU information from the library entirely. If people need information about the GPU, getting it from Vulkan, DirectX, OpenGL, or OpenCL is already really well documented. Those standards [and similar] are really the only places people would need it anyhow.

I'm not trying to be rude, but there really is zero reason to include it. For people who are already using one of these frameworks, adding OpenCL on top of it is unacceptable in most cases especially considering OpenCL is on its way out the door to be replaced with other alternative frameworks.

Edit: Had a quick think. It'd probably be better to make the entire library modular. You already have the library well divided as appropriate, making it modular seems like a very safe next step. In other words, I mean making the motherboard, battery, CPU, etc. dependent on user choice.

F35H avatar Jul 07 '24 09:07 F35H

Thank you for your thoughts. I think, that modularity would indeed increase the library's usability.

I'll take this task as soon as possible. Coworkers and ideas are welcome!

lfreist avatar Jul 07 '24 17:07 lfreist

Continued in #94

lfreist avatar Jul 07 '24 18:07 lfreist