Hi!

On 2022-04-29T15:48:03+0200, I wrote:
> On 2022-04-06T11:57:57+0200, Tom de Vries <tdevries@suse.de> 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