Open voidxno opened 6 days ago
Yeah this is currently a limitation...
If/when reworked (no priority before mainnet from my side). Found another limitation, identical platform names (just documenting it here).
Was VDF-verify testing an Intel Arc A380 GPU on my Intel 265K. Giving 2x OpenCL devices:
To illustrate. Also ran the platform with RTX 3050 + GT 1030. 3x OpenCL devices:
Output from clinfo -l
:
Platform #0: Intel(R) OpenCL Graphics
`-- Device #0: Intel(R) Graphics [0x7d67]
Platform #1: Intel(R) OpenCL Graphics
`-- Device #0: Intel(R) Arc(TM) A380 Graphics
Platform #0: NVIDIA CUDA
+-- Device #0: NVIDIA GeForce RTX 3050
`-- Device #1: NVIDIA GeForce GT 1030
Platform #1: Intel(R) OpenCL Graphics
`-- Device #0: Intel(R) Graphics [0x7d67]
Don't know why, or how often will happen. But Intel iGPU and Intel Arc GPU have two different OpenCL platforms, with identical name (Intel(R) OpenCL Graphics
). Not a problem with NVidia, has 2x devices on same OpenCL platform.
As mmx-node does this now. I do not get 'Intel(R) Arc(TM) A380 Graphics' as a choice, only 'Intel(R) Graphics [0x7d67]'. Workaround for now is to disable iGPU in BIOS.
Stupid Intel lol...
I think we should merge platform + device into a single config. Just show device name, and internally switch platform if needed.
Yeah. Intel certainly on a run these days, just not in the right directions :-|
Wouldn't mind giving it a go, already looked at the code. Would something like this be a starting point ?
Visual:
Logical:
Extra thoughts:
I would keep the index for opencl_device
. The only reason we use the string for platform is because the order is undefined, whereas the device order per platform is deterministic.
But if there are duplicate platform names, this wont work anyways... Need to find something else other than name or index to identify platform. This will require modifying basic_opencl
.
Only list device name (simple/clean) -> Yes
Think I see the issue if using ::find_platform_by_name()
like it is now (in mmx-node).
My thought was enumerating, at start, all platforms and devices in 4x lists (psudo edition):
plat_idx | plat_name | dev_idx | dev_name
---------+--------------------------+---------+-------------------------------
0 | Intel(R) OpenCL Graphics | 0 | Intel(R) Graphics [0x7d67]
1 | Intel(R) OpenCL Graphics | 0 | Intel(R) Arc(TM) A380 Graphics
Then decide which platforms[x]
to use by match of both 'plat_name' and 'dev_name'. Instead of ::find_platform_by_name()
.
No need to change basic_opencl
. Call to ::basic_opencl::get_platforms()
return two entries, even in identical name case.
Bonus: Adding hardware/GPU, in addition to existing, that changes order, still correct device used next time.
Could be pitfalls/angles I'm missing. Framework compatibility with other projects. A need to keep opencl_device
as index in mmx-node.
Duh. I just created a reverse problem.
What if two identical devices installed (like 2x RTX 3050). Will list them both. But would never be able to activate second. So need to config-store an 'index' in some form, yeah.
How to do it simple/elegant. Was hoping not triggering a change to basic_opencl
.
Just FYI: clinfo.txt attachment of both iGPU & Arc A380 present. Cannot find any identifier that differentiate between the two Intel platforms. Maybe OpenCL API has some, but not shown in clinfo.
And, cannot use index save-config for platform (per the undefined order).
I think your idea of searching multiple platforms to find the selected device will work. So we need to store both device name + device index, and no platform name.
Just a bit more tricky to implement on WebGUI side, but I can do that.
Hmm but this will make manual config edit more difficult. Maybe we add a fallback to the current method if device name is not specified.
Was hoping not triggering a change to basic_opencl.
If it's just adding a new function, it's no problem. This is my library.
Ok I would add opencl_device_name
config. And then fallback to current method (plat name + dev index) if this config is not specified. In case opencl_device_name
is specified then opencl_device
becomes a relative index, instead of absolute, to specify which card to use in case of multiple duplicates.
The new opencl.device_list_all
config needs to be an array of objects: [{name: ..., index: <relative>, platform: <name>}, ...]
And the WebGUI needs to be updated to display opencl.device_list_all
correctly, and set both opencl_device_name
and opencl_device
, and maybe even opencl.platform
. If opencl.platform
is not specified we search through all, otherwise limit the search to the given platform name.
Sounds sound:
platform
(opencl.json): No saved device name = legacy/migrate config value.opencl_device
(Node.json): No saved device name = legacy/migrate config value. Else, -1: CPU, >=0: relative index.opencl_device_name
(Node.json): New config value, device name to use (search for).Manual config (no WebGUI):
Goal:
Request:
opencl_device_name
(Node.json) config value (string) with your vnx magic.I pushed it on master.
Even better, thx.
Got following OpenCL hardware:
Intel(R) OpenCL Graphics
Intel(R) Graphics [0x7d67]
NVIDIA CUDA
NVIDIA GeForce RTX 3050
Issue: In WebGUI / SETTINGS. When switching between the two 'OpenCL Platform'. The 'OpenCL Device' list is not refreshed. It stays with device list it was initialized with (startup). Is cosmetic (to a certain degree). After mmx-node restart (needed anyway), Device is label'ed correctly.
Not a very important issue. Mostly cosmetic. Can be a case if 1x device on one platform, 2x devices on next. Might not be able to WebGUI select 2nd device on second platform (until restart of mmx-node).
Took a look at source:
Node.cpp
populates list of platforms inopencl.platform_list
Node.cpp
populates list of devices inopencl.device_list
(but only for currently active platform)settings.js
gets data throughWebAPI.cpp
and/wapi/config/get
settings.js
populatesopencl_platform_list
andopencl_device_list
settings.js
no refresh ofopencl_device_list
, when drop-downopencl_platform_list
Maybe solution:
Node.cpp
populate data with two-dim array with devices from all platformssettings.js
to act on this available dataNot a priority. Just wanted an issue to refer to if comes up.