search for: sergo

Hello everybody! To continue the original (http://article.gmane.org/gmane.comp.compilers.llvm.devel/75674) discussion of offload infrastructure I have an updated document with more details for your attention. The document is a consensus of the contributors representing a number of institutions: ANL, AMD, IBM, Intel and Texas Instruments. Our intent is to have a discussion and an approval from

...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 accessibility issue...

Hi Sergos and Samuel, Thanks for the links, I've got it mostly working now. I still have a problem with linking the code. It seems that the clang driver doesn't pass its library search path to nvlink when linking the generated cuda code to the target library, resulting in it not correctly find...

...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 some more. As for the OpenMP examples I can recommend you the http://openmp.org/mp-documents/OpenMP4.0.0.Examples.pdf look into the target constructs. 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 w...

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 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii < &gt...

...ned above has an operable implementation fon NVIDIA target at the https://github.com/clang-omp/llvm_trunk https://github.com/clang-omp/clang_trunk with runtime implemented at https://github.com/clang-omp/libomptarget you're welcome to try it out, if you have an appropriate device. Regards, Sergos On Sat, Jun 6, 2015 at 2:24 PM, Christos Margiolas <chrmargiolas at gmail.com> wrote: > Hello, > > Thank you a lot for the feedback. I believe that the heterogeneous engine > should be strongly connected with parallelization and vectorization efforts. > Most of the accelerato...

Hi Sergos, 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 al...

...-use the SE in other parallel models. As for being GPU-centric: 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...

...nd 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 reference....

...t file as host code. It is intended to ease adoption of the heterogeneous approach: there should be no changes to build scripts. The resultant executable/library obtained from the build should be self-contained and user will have no extra problems with target objects/files availability at rutnime. Sergos. On Mon, Mar 28, 2016 at 9:47 PM, Jason Henline via cfe-dev < cfe-dev at lists.llvm.org> wrote: > 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 b...

...gt; 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 believe i...

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

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

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 believe it will be good to have input from community at this early stage before moving deeper in details. The driver part is intentionally not touched, since we have no clear vision on how one can

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

On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii < Dmitrii.Kuvaiskii at tu-dresden.de> wrote: > >> Recently I played with MPX support on Intel C/C++ Compiler (icc). This > >> implementation looks *much* better, with the following example > >> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on > >> "streamcluster".

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

...to account different application of the compiler and infrastructure: there can be server solutions where we are free to use full-featured C++ and there can be embedded solutions, such as automotive, where customers are tend to have as few runtime support as possible and like C the most. Regards, Sergos Intel Compilers On Sat, Apr 23, 2016 at 1:24 AM, Chandler Carruth via Openmp-dev < openmp-dev at lists.llvm.org> wrote: > On Fri, Apr 22, 2016 at 3:05 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> > On Apr 22, 2016, at 3:01 PM, Chandler Carruth <...

Christos, We would be very interested in learning more about this. In my group, we (Prakalp Srivastava, Maria Kotsifakou and I) have been working on LLVM extensions to make it easier to target a wide range of accelerators in a heterogeneous mobile device, such as Qualcomm's Snapdragon and other APUs. Our approach has been to (a) add better abstractions of parallelism to the LLVM instruction

> On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I feel like this thread got a bit stalled. I'd like to pick it up and try to suggest a path forward. > > I don't hear any real objections to the overall idea of having an LLVM subproject for parallelism runtimes and support libraries. I think we should get that created. I think it