Artem Belevich via llvm-dev
2021-Nov-11 18:51 UTC
[llvm-dev] Should we have a "GPU working group"?
+cc: yaxun.liu at amd.com for HIP. Also, count me in. On Thu, Nov 11, 2021 at 10:32 AM Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> +1, count me in. > > Cheers, > -Quentin > > On Nov 11, 2021, at 10:22 AM, Jason Eckhardt via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > +1 here as well, even if in lurk mode initially. > > Some additional topics of interest: > > 1. *Occupancy vs resource trade-offs (especially registers)*. Requires > closer coordination of scheduling + register allocation, in addition to > extensions in each. > 2. *Divergence analysis/uniformity analysis*. Applications to sync > insertion, scalar vs vector register allocation, instruction selection, etc. > 3. *Synchronization insertion*. Some GPUs have instructions to hint > where a good re-convergence point is. > 4. *Global instruction scheduling*. Some GPU code is surprisingly > branchy. Numerous out-of-tree/proprietary global schedulers have been > written, we *still* don't have one upstream. > 5. I*ncreasing overall back-end speed for JIT compilation*. GPU > back-ends are often situated within graphics drivers where they dynamically > compile shaders with absurdly stringent timing constraints. GlobalISel is a > step in the right direction, but more needs doing (particularly for small > shaders). > > As an example, #1 is handled (if at all) specially by each target. With > the proliferation of GPUs (Teams Red, Green, Blue, and others), it would be > useful for "all boats to float higher" with generic code (with > target-specific hooks/overrides) supported by the wider community as > opposed to redundant re-invention of the wheel (or no wheel at all, as in > #4). Then specific targets can expend effort adding value for their > particular needs. > > ------------------------------ > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Lei Zhang > via llvm-dev <llvm-dev at lists.llvm.org> > *Sent:* Thursday, November 11, 2021 9:44 AM > *To:* Valentin Churavy <v.churavy at gmail.com> > *Cc:* Lieberman, Ron <Ron.Lieberman at amd.com>; justin.lebar at gmail.com < > justin.lebar at gmail.com>; Chesterfield, Jonathan < > Jonathan.Chesterfield at amd.com>; llvm-dev at lists.llvm.org < > llvm-dev at lists.llvm.org>; tianshilei1992 at gmail.com < > tianshilei1992 at gmail.com>; Rodgers, Gregory <Gregory.Rodgers at amd.com>; > Huber, Joseph <huberjn at ornl.gov>; Narayanaswamy, Ravi < > ravi.narayanaswamy at intel.com> > *Subject:* Re: [llvm-dev] Should we have a "GPU working group"? > > *External email: Use caution opening links or attachments* > +1. There are certainly efforts that need broad collaboration among > various interest parties; they would benefit from more interactive > discussions to have everybody on the same page. What immediately jumps into > my mind include how we can push to have unified/better SPIR-V support in > LLVM proper / cross LLVM/MLIR, etc. It's a big one that I'd assume will > take a long time to unfold and will have back and forth. Having a place to > discuss will actually make sure we put efforts towards it (or at least have > plans and revisit periodically). There are certainly many other topics to > discuss too, as said by Johannes. I think this is a great idea. > > Thanks, > Lei > > > On Wed, Nov 10, 2021 at 4:03 PM Valentin Churavy via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I would certainly be interested in joining such an effort. > > -V > > On Wed, Nov 10, 2021 at 3:56 PM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hey, > > We nowadays have various "working groups" that meet regularly to discuss > technical topics (incl. RISC-V, MLIR, OpenMP, Alias Analysis, ML, Flang, > ...). > It's a reasonably nice way for people to connect and present ideas, get > feedback, etc. in an interactive environment. > While the OpenMP meeting has a strong emphasis on offloading, we do not > meet to discuss "generic GPU" topics as a community. > > This email is to determine if people would be interested in meeting once > every N weeks (initially we could say 2) to coordinate efforts in this > space, e.g., development of GPU-specific optimizations, organization of > driver and backend code, dealing with issues like convergent functions, ... > > I CC'ed a bunch of people that might want to join such a meeting but > certainly this is something everyone would be invited to and I hope > people forward this to parties that might not read llvm-dev. > > Looking forward to hear what people think :) > > ~ Johannes > > > > > -- > ─────────────────── > ∽ Johannes (he/his) > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cjeckhardt%40nvidia.com%7Cea5003810a644cc981b308d9a52a252b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637722422720796637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Wqe0548FXifuicYy39N8YafF3IUqZaATKgAYHctuPv4%3D&reserved=0> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cjeckhardt%40nvidia.com%7Cea5003810a644cc981b308d9a52a252b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637722422720806639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5ygaPNgaF5YXRlFV1wF9VajRsEZsySt7z2OCHokcHBc%3D&reserved=0> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- --Artem Belevich -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211111/256db80c/attachment.html>
+1 On Thu, Nov 11, 2021 at 10:51 AM Artem Belevich via llvm-dev < llvm-dev at lists.llvm.org> wrote:> +cc: yaxun.liu at amd.com for HIP. > > Also, count me in. > > On Thu, Nov 11, 2021 at 10:32 AM Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> +1, count me in. >> >> Cheers, >> -Quentin >> >> On Nov 11, 2021, at 10:22 AM, Jason Eckhardt via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> +1 here as well, even if in lurk mode initially. >> >> Some additional topics of interest: >> >> 1. *Occupancy vs resource trade-offs (especially registers)*. >> Requires closer coordination of scheduling + register allocation, in >> addition to extensions in each. >> 2. *Divergence analysis/uniformity analysis*. Applications to sync >> insertion, scalar vs vector register allocation, instruction selection, etc. >> 3. *Synchronization insertion*. Some GPUs have instructions to hint >> where a good re-convergence point is. >> 4. *Global instruction scheduling*. Some GPU code is surprisingly >> branchy. Numerous out-of-tree/proprietary global schedulers have been >> written, we *still* don't have one upstream. >> 5. I*ncreasing overall back-end speed for JIT compilation*. GPU >> back-ends are often situated within graphics drivers where they dynamically >> compile shaders with absurdly stringent timing constraints. GlobalISel is a >> step in the right direction, but more needs doing (particularly for small >> shaders). >> >> As an example, #1 is handled (if at all) specially by each target. With >> the proliferation of GPUs (Teams Red, Green, Blue, and others), it would be >> useful for "all boats to float higher" with generic code (with >> target-specific hooks/overrides) supported by the wider community as >> opposed to redundant re-invention of the wheel (or no wheel at all, as in >> #4). Then specific targets can expend effort adding value for their >> particular needs. >> >> ------------------------------ >> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Lei >> Zhang via llvm-dev <llvm-dev at lists.llvm.org> >> *Sent:* Thursday, November 11, 2021 9:44 AM >> *To:* Valentin Churavy <v.churavy at gmail.com> >> *Cc:* Lieberman, Ron <Ron.Lieberman at amd.com>; justin.lebar at gmail.com < >> justin.lebar at gmail.com>; Chesterfield, Jonathan < >> Jonathan.Chesterfield at amd.com>; llvm-dev at lists.llvm.org < >> llvm-dev at lists.llvm.org>; tianshilei1992 at gmail.com < >> tianshilei1992 at gmail.com>; Rodgers, Gregory <Gregory.Rodgers at amd.com>; >> Huber, Joseph <huberjn at ornl.gov>; Narayanaswamy, Ravi < >> ravi.narayanaswamy at intel.com> >> *Subject:* Re: [llvm-dev] Should we have a "GPU working group"? >> >> *External email: Use caution opening links or attachments* >> +1. There are certainly efforts that need broad collaboration among >> various interest parties; they would benefit from more interactive >> discussions to have everybody on the same page. What immediately jumps into >> my mind include how we can push to have unified/better SPIR-V support in >> LLVM proper / cross LLVM/MLIR, etc. It's a big one that I'd assume will >> take a long time to unfold and will have back and forth. Having a place to >> discuss will actually make sure we put efforts towards it (or at least have >> plans and revisit periodically). There are certainly many other topics to >> discuss too, as said by Johannes. I think this is a great idea. >> >> Thanks, >> Lei >> >> >> On Wed, Nov 10, 2021 at 4:03 PM Valentin Churavy via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> I would certainly be interested in joining such an effort. >> >> -V >> >> On Wed, Nov 10, 2021 at 3:56 PM Johannes Doerfert via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Hey, >> >> We nowadays have various "working groups" that meet regularly to discuss >> technical topics (incl. RISC-V, MLIR, OpenMP, Alias Analysis, ML, Flang, >> ...). >> It's a reasonably nice way for people to connect and present ideas, get >> feedback, etc. in an interactive environment. >> While the OpenMP meeting has a strong emphasis on offloading, we do not >> meet to discuss "generic GPU" topics as a community. >> >> This email is to determine if people would be interested in meeting once >> every N weeks (initially we could say 2) to coordinate efforts in this >> space, e.g., development of GPU-specific optimizations, organization of >> driver and backend code, dealing with issues like convergent functions, >> ... >> >> I CC'ed a bunch of people that might want to join such a meeting but >> certainly this is something everyone would be invited to and I hope >> people forward this to parties that might not read llvm-dev. >> >> Looking forward to hear what people think :) >> >> ~ Johannes >> >> >> >> >> -- >> ─────────────────── >> ∽ Johannes (he/his) >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cjeckhardt%40nvidia.com%7Cea5003810a644cc981b308d9a52a252b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637722422720796637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Wqe0548FXifuicYy39N8YafF3IUqZaATKgAYHctuPv4%3D&reserved=0> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cjeckhardt%40nvidia.com%7Cea5003810a644cc981b308d9a52a252b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637722422720806639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5ygaPNgaF5YXRlFV1wF9VajRsEZsySt7z2OCHokcHBc%3D&reserved=0> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > --Artem Belevich > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211111/4edb0288/attachment.html>