Hi Roger! On 2022-04-05T19:46:08+0100, "Roger Sayle" <ro...@nextmovesoftware.com> wrote: > I apologise that it might complicate things
No worries; that's why I asked. :-) > one potential benefit of --with-cuda-driver > (i.e. linking the compiler against proprietary libraries) is that it would > allow support for > -march=native on nvptx (i.e. the gcc driver can figure out what sm_xx is > available on the > GPU(s) of the current machine, and pass that to cc1. Like with all the > microarchitectures > on other platforms (x86_64), figuring this out is not a trivial task for many > end-users. Ah, interesting idea! (I suppose still not too relevant right now, but once we've got GCC/nvptx multilibs making better use of modern PTX features, I certainly do see the point.) > Of course, ideally I'd love to be able to figure out the PTX hardware > specifications and > driver versions without using a third-party library, but I've no idea how > this could be done > (portably across the platforms that support libcuda). Perhaps dlopen at > runtime? > Or calling out to (executing) nvptx-tools? Indeed I suppose I'd do this via 'dlopen', and not directly link GCC against 'libcuda.so' etc.: so that the GCC build may also be used on a system where no 'libcuda.so' is available. So -- sorry ;-) -- that's not a show-stopper for removing the '--with-cuda-driver' etc. 'configure'-time options. 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
