[RFC] `llvm-project/offload` roadmap

[jdoerfert]

@JonChesterfield

I still object.

Noted. As I see it, you want us to go a different way and it seems non-resolvable.
I tried to alleviate some of your early concerns with the encapsulation of features, but it seems that was not enough.
At this point, short of moving to your solution, I am unsure there is anything we can do, is there?
Which means we are either deadlocked or we commit to something and develop from there.
Talking to others again, I believe this RFC has a broad majority backing it.
Rewriting APIs and other things you want to do are obviously not out of the question, we can, and want to still do that as we develop this.

@JonChesterfield

As stated previously, I believe we have enthusiastic support for a LLVM GPU offloading library that is used by multiple different languages, in and out of tree. We are all tired of targeting multiple different vendor libraries and would like a common abstraction. We have an opening to do something really useful here.

Good.

@JonChesterfield

Your plan of record is mv libomptarget LLVMGPU then comprehensively rewrite. I do not see support for that from any group other than openmp developers, and even those developers have mixed feelings about the rewrite part. People want their pain point addressed, it does not follow that they want you to do this.

This is odd. Above I see people working on 3+ different programming models targeting 3+ different accelerators supporting this RFC. If we include the original RFC I made, people working on 5+ established and a few researchy programming models have commented positively on the goal and for the most part not objected to the path.

@JonChesterfield

Instead of your plan, I maintain that we should create a LLVMGPU project, write an API for it which has features like “find a kernel” and “launch a kernel” which aren’t interwoven with openmp semantics. We then use that library as part of the implementation of openmp and other users. That follows the collection of reusable libraries strategy of LLVM which I believe does and should have widespread support.

I don’t see why your goal is different from mine or somehow excluded by the proposed path. There is no need to start from scratch to achieve what you are describing.
We can have that exact API and we can use it without OpenMP semantics. The POC shows this nicely.

@JonChesterfield

I have concerns about your plan to move libomptarget and then immediately rewrite it. Given that’s the intent, you should write your new library instead and optionally use it from libomptarget. That drastically reduces the risk of breaking users of libomptarget and has zero effect on your stated development plan. It also leaves you free to write a more useful language agnostic interface, free of the existing API. That is the technically superior strategy to achieve your stated goals and I am totally bewildered that you are unwilling to consider it.

We talked about this in details for hours, on at least 3 different occasions. I would not describe it as “me not considering it”.

Wrt. downstream users (esp. AMD): Why would you not just keep openmp/libomptarget downstream and the end result is the same for you? No breakage for you downstream even if we change the API and such.

@JonChesterfield

I also have concerns that you have been unwilling to engage with AMD engineers about this strategy, given that the ROCm compiler is the only downstream compiler that uses libomptarget (based on attendance in the multicompany openmp meeting). Intel and HPE both use their own library and are thus unaffected by this change, except for where you subsequently break the API as planned above. I am arguing internally that AMD should likewise abandon your library in favour of a hard fork of the runtime libraries until such time as the new GPU offloading library becomes equivalently usable to the one currently in tree.

Again, I spend hours talking to multiple AMD people 1-on-1 in addition to the many hours we spend on this in the OpenMP meetings. I walked you personally though the rational multiple times. I also discussed it with others that are now working on documents to discuss in our new meeting (see @jhuber6 post above).

AMD is not the only downstream compiler that uses libomptarget. I am unsure why you would think that. Intel, for example, uses upstream libomptarget with extensions and they regularly apply patches. Their fork is open, you can look. I know of multiple other compilers with (experimental) lowering to libomptarget.
All that said, if your concern is that LLVM/Offload is going to be unstable for your downstream compiler, it should be easy to not opt-in at the beginning. As mentioned above, you can keep libomptarget around and simply ignore LLVM/Offload until you have confidence to switch over.

@JonChesterfield

You consider my suggestion to take too long relative to hacking things together. That fundamentally misunderstands that the purpose of a common library. The goal should be to reduce the implementation cost of GPU languages, not minimise the implementation cost of the common library. A library called “LLVM GPU” which contains all the bugs and quirks of OpenMP is not going to decrease the implementation cost for anyone.

I don’t see why the proposed path makes it impossible or harder to spend time isolating OpenMP “quirks” after we moved. We would always have a working solution that we can rewrite as we do it right now. Patch after patch it would make OpenMP quirks “opt-in” (as not all non-OpenMP languages would necessarily always want to opt-out of all the features).

@callumfare

The combination of multiple components in libomptarget may also confuse things (host runtime, plugins-nextgen, DeviceRTL). If the goal is simply to create a library that abstracts away specific GPU APIs then the new library would only have to replace the plugins and the remaining libomptarget components could remain OpenMP specific.

I don’t think I understand how one could not have a layer to select the right plugin/adaptor. I mean, you have 4 devices, where is device 3 mapped to the X86 plugin and device 4 to NVIDIA? That said, I can see how you could move other libomptarget capabilities into the plugins if we want to. Linking the plugins into libomptarget statically is already on the TODO list; in case the dynamic loading was your issue with the two libraries.