Hi! Ping. Grüße Thomas On 2022-05-13T14:29:01+0200, I wrote: > Hi! > > On 2022-04-29T15:48:03+0200, I wrote: >> On 2022-04-06T11:57:57+0200, Tom de Vries wrote: >>> On 4/5/22 17:14, Thomas Schwinge wrote: >>>> Regarding [...] > >>>> Now, consider doing a GCC/nvptx offloading build with >>>> '--with-cuda-driver' [...] > >>> Thanks for reminding me, I forgot about this configure option. >> >> OK, good. ;-) > > (It also wasn't documented, by the way...) > >> [...] we seem to agree that '--with-cuda-driver' is not >> very useful, and may be removed: >> >>>> Already long ago Jakub put in changes to use '--without-cuda-driver' to >>>> "Allow building GCC with PTX offloading even without CUDA being installed >>>> (gcc and nvptx-tools patches)": "Especially for distributions it is >>>> undesirable to need to have proprietary CUDA libraries and headers >>>> installed when building GCC.", and I understand GNU/Linux distributions >>>> all use that. That configuration uses the GCC-provided >>>> 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually >>>> define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'. >>>> (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for >>>> example.) Quite likely that our group (at work) are the only ones to >>>> actually use '--with-cuda-driver'? >>> >>> Right, I see in my scripts that I don't use --with-cuda-driver, possibly >>> because of years-ago running into issues when changing drivers forth and >>> back. >>> >>>> My proposal now is: we remove '--with-cuda-driver' (make its use a no-op, >>>> per standard GNU Autoconf behavior), and offer '--without-cuda-driver' >>>> only. This shouldn't cause any user-visible change in behavior, so safe >>>> without a prior deprecation phase. >>> >>> I think the dlopen use-case is the most flexible, and I don't see any >>> user benefit from using --with-cuda-driver, so I don't see a problem >>> with removing --with-cuda-driver for the user. >> >> ACK, thanks. >> >>> I did wonder about keeping it available in some form, say rename to >>> --maintainer-mode-with-cuda-driver. This could be useful for debugging >>> / comparison purposes. But it would mean having to test it when making >>> relevant changes, which is maintenance burden for a feature not visible >>> to the user, so I guess that's not worth it. >>> >>> So, I'm fine with removing. >> >> Based on the point you made above, I realized that it may be beneficial >> to "keep the underlying functionality available for the developers": >> "if you develop CUDA API-level changes in the libgomp nvptx plugin, it's >> likely to be easier to just use the full CUDA toolkit 'cuda.h' and >> directly link against libcuda (so that you've got all symbols etc. >> available), and only once you know what exactly you need, update GCC's >> 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'". (See the >> thread "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into >> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'".) >> >> Do we agree that it's OK to remove the user-visiable '--with-cuda-driver' >> etc. options, and do not introduce any new >> '--enable-maintainer-mode-with-cuda-driver' (or similar) option, and >> instead let this functionality be available to developers only, via >> manually editing 'libgomp/plugin/Makefrag.am'? >> >> Happy to submit an illustrative patch, if that helps. > > Well, given the preparational work that I've put in in the last days, > attached now actually is the final patch: "libgomp nvptx plugin: > Remove '--with-cuda-driver=[...]' etc. configuration option". OK to > push? > > > Grüße > Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955