search for: ostanevich

...contributors representing a number of institutions: ANL, AMD, IBM, Intel and Texas Instruments. Our intent is to have a discussion and an approval from the community on the method we are going to implement, so when the time to submit patches will come there will be no surprises. Thank you, Sergey Ostanevich Open Source Compilers Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: offload-proposal-intel-ti-ibm.pdf Type: application/pdf Size: 238840 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150408/225ab427/...

...n't see any other issues. I strongly believe the approach described in the document is a nice way to get OpenMP offloading support in clang. I plan to start actively contributing code for this component of the OpenMP implementation soon. Thanks again, Samuel 2015-04-29 11:47 GMT-04:00 Sergey Ostanevich <sergos.gnu at gmail.com>: > Hi! > > Here's an updated version - couple of misprints are fixed. Thank you > to Roel Jordans and Kelvin Li for pointing this out. > I put this on Google drive to avoid the mailing list restrictions, > feel free to complain on the accessibi...

...clear vision on how one can use 3rd party compiler for target code generation and incorporate its results into the final host link phase. I hope to hear from you more on this. I invite you to take part in discussion of the document. Critics, proposals, updates - all are welcome! Thank you, Sergey Ostanevich Open Source Compilers Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: offload-proposal.pdf Type: application/pdf Size: 684900 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140809/cd6c7f7a/attachment.pd...

...ations in the > lower-level runtime. > > I think this can be solved by the target dependent RTL alone by returning the number of available devices to libtarget.so based on some env variable specified by the RTL. > > cheers > john > > > On Aug 8, 2014, at 5:22 PM, Sergey Ostanevich <sergos.gnu at gmail.com> > wrote: > > > Hello everybody! > > > > I would like to present a proposal for implementation of OpenMP > > offloading in LLVM. It was created by a list of authors and covers the > > runtime part at most and at a very high level. I...

...ucts. Sergos On Mon, Jun 8, 2015 at 6:13 PM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Sergos, > > I'd like to try this on our hardware. Is there some example code that I > could use to get started? > > Cheers, > Roel > > > On 08/06/15 13:27, Sergey Ostanevich wrote: >> >> Chirs, >> >> Have you seen an offloading infrastructure design proposal at >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084986.html ? >> It relies on the long-standing OpenMP standard with recent updates to >> support the heterogeno...

...be > in LLVM IR. However, the goal seems to be the same. Hope the summary > above gives you some hints on whether your use cases can be accommodated. > > Feel free to ask any questions you may have. > > Thanks! > > Samuel > > > > 2015-06-08 16:46 GMT-04:00 Sergey Ostanevich <sergos.gnu at gmail.com > <mailto:sergos.gnu at gmail.com>>: > > Roel, > > You have to checkout and build llvm/clang as usual. > For runtime support you'll have to build the libomptarget and make a > plugin for your target. Samuel can help you s...

Dmitrii, all, Please note, that GCC 5.3 had a significant update to the MPX code quality - please, use this version as reference. Regards, Sergos On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Thu, Feb

...line, I will send the draft to />>/everyone who took part in this conversation, just to be on the safe />>/side and correct any bugs/wrong conclusions. />>//>//>/I would appreciate this. />//>/--kcc />//>//>>//>>/On Tue, Feb 9, 2016 at 3:24 PM, Sergey Ostanevich <sergos.gnu at gmail.com <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> />>/wrote: />>>/Dmitrii, all, />>>//>>>/Please note, that GCC 5.3 had a significant update to the MPX code />>/quality - />>>/please, use this version as...

On 08/11/14 01:03 PM, Das, Dibyendu wrote: > I didn’t see SPIR discussed anywhere. This isn't OpenCL and depending on OpenCL for OpenMP may not really make sense. While I have my own opinions - If you feel strongly that it will help enable higher performance somewhere please list those reasons. ---------- More specifically LLVM has a native AMD dGPU backend that is tightly coupled to the

On 08/11/14 07:32 PM, Das, Dibyendu wrote: > Storing llvm-ir in the fat binary may have the same performance issues mentioned below. The fat binary discussed in the proposal has provision for storing the isa/llvm-ir. My point is instead of llvm-ir it shd be something like spir. Ok - so lets see some data. #1 Benchmarks showing at least SPIR dgemm/sgemm performance #2 Some logical explanation

Chandler, Thank you for getting it up to ML top. I believe we have to move broader than that you just mentioned. The natural separation of the infrastructure into different parts can be across the following lines: - the parallel model of programming - these can be OpenMP, OpenACC, CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc. - the offloading machinery to be used by any

...is it a decision to follow in the future, or do you envision some uniform device support? Say, if device hasn't a two-level 'block and dim' hierarchy as in your interface. What should be in the plugin implementation then? Sergos -Jason > > On Mon, Mar 28, 2016 at 2:31 PM Sergey Ostanevich <sergos.gnu at gmail.com> > wrote: > >> Jason, >> >> Am I got it right, that SE interfaces are bound to the stream that is >> passed as argument? As I can see the stream is an abstraction of the target >> - hence data transfers for particular stream is limi...

...as in memory. You are right that using files requires users to change build files; that's part of the reason we want clang to be able to emit SE calls. That way the kernel can be stored in memory and the user won't have to think much about it. -Jason On Mon, Mar 28, 2016 at 2:31 PM Sergey Ostanevich <sergos.gnu at gmail.com> wrote: > Jason, > > Am I got it right, that SE interfaces are bound to the stream that is > passed as argument? As I can see the stream is an abstraction of the target > - hence data transfers for particular stream is limited to this stream? > As f...

Chirs, Have you seen an offloading infrastructure design proposal at http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084986.html ? It relies on the long-standing OpenMP standard with recent updates to support the heterogenous computations. Could you please review it and comment on how it fits to your needs? It's not quite clear from your proposal what source language standard do you

...my points above are invalid - can someone clarify that SE and the "stuff" in OpenMP-llvm doesn't actually overlap in functionality. On Mon, Apr 25, 2016 at 11:46 PM, Chandler Carruth via cfe-dev <cfe-dev at lists.llvm.org> wrote: > On Mon, Apr 25, 2016 at 11:41 AM Sergey Ostanevich via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Chandler, >> >> Thank you for getting it up to ML top. >> >> I believe we have to move broader than that you just mentioned. The >> natural separation of the infrastructure into different par...

Jason, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? Regarding

Alexandre, Thanks for further shedding some light on the way OpenMP handles dependencies between tasks. I'm sorry for leaving that out of my document, it was just because I didn't know much about the way OpenMP handled its workflows. On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote: > Hi Carlo, > > Thanks for helping to clarify this point about

I think it would be great if StreamExecutor could use liboffload to perform its offloading under the hood. Right now offloading is handled in StreamExecutor using platform plugins, so I think it could be very natural for us to write a plugin which basically forwards to liboffload. If that worked out, we could delete our current plugins and depend only on those based on liboffload, and then all the