You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, architecture is the only argument that let us specify for which CPU microarchitecture we want to build software packages. For accelerators/GPUs, we want to be able to build for specific combinations of CPUs and accelerators/GPUs - instead of building "fat" GPU binaries (which might not work or may be undesired) and avoiding to build many combinations for which we likely don't find any existing system (e.g, haswell + A100).
A new argument accelerator could take any value that is passed through to the build script and interpreted there only. Benefit of introducing a new argument would be that we don't have to change the semantics and processing of existing arguments ... or at least changes hopefully will be minimal.
Adding a new argument that also starts with an a will require a few changes to avoid ambiguities with the existing argument architecture, e.g., we could require that any argument is given with at least three of its starting characters (arc for architecture and acc for accelerator).
The parsing for the arguments has to be extended as well as the check if an EESSIActionFilter matches a context. We also need to add the argument and its value to the cfg/job.cfg file.
Currently,
architecture
is the only argument that let us specify for which CPU microarchitecture we want to build software packages. For accelerators/GPUs, we want to be able to build for specific combinations of CPUs and accelerators/GPUs - instead of building "fat" GPU binaries (which might not work or may be undesired) and avoiding to build many combinations for which we likely don't find any existing system (e.g,haswell
+A100
).A new argument
accelerator
could take any value that is passed through to the build script and interpreted there only. Benefit of introducing a new argument would be that we don't have to change the semantics and processing of existing arguments ... or at least changes hopefully will be minimal.Adding a new argument that also starts with an
a
will require a few changes to avoid ambiguities with the existing argumentarchitecture
, e.g., we could require that any argument is given with at least three of its starting characters (arc
forarchitecture
andacc
foraccelerator
).The parsing for the arguments has to be extended as well as the check if an
EESSIActionFilter
matches a context. We also need to add the argument and its value to thecfg/job.cfg
file.For further information, see https://github.com/EESSI/meetings/wiki/bot-sync-meeting-2024-06-14
The text was updated successfully, but these errors were encountered: