search for: rodinia

Hi all, As part of my research I want to investigate the relation between the grid's geometry and the memory accesses of a kernel in common gpu benchmarks (e.g Rodinia, Polybench etc). As a first step i want to answer the following question: - Given a kernel function with M possible memory accesses. For how many of those M accesses we can statically infer its location given concrete values for the grid/block and executing thread? (Assume CUDA only for now) My...

...for strictly control-flow structured languages (OpenCL, GLSL). The code includes a drop-in OpenCL driver that allows source-to-source OpenCL code transformations on existing OpenCL applications. The OpenCL backend has been under development for a while now and was tested against the NVIDIA, AMD and Rodinia demo/benchmark suites with recent NVIDIA/AMD drivers. Results for NVIDIA and AMD show, with few exceptions, that the source-to-source-loop does not introduce any performance penalty on the generated kernels (known exception: AES on recent AMD drivers), However, kernels with sampler types are curre...

...on (create vector instructions out of multiple work-items) and a customized kernel buffer allocator. Even though the OpenCL 1.2 standard is not yet implemented fully and it contains known bugs, we now consider pocl ready for wider scale testing. pocl 0.6 compiles and runs successfully most of the Rodinia benchmark, all of ViennaCL test cases, and most of the OpenCL Programming Guide samples. Links ----- Download: http://launchpad.net/pocl/TODO Home page/wiki: http://pocl.sourceforge.net/ This announcement: http://launchpad.net/pocl/TODO Change log: http://luanchpad.net/pocl/T...

...ohannes > > > > > On 8/22/20 9:38 AM, Ees Kee via llvm-dev wrote: > > Hi all, > > > > As part of my research I want to investigate the relation between the > > grid's geometry and the memory accesses of a kernel in common gpu > > benchmarks (e.g Rodinia, Polybench etc). As a first step i want to > > answer the following question: > > > > - Given a kernel function with M possible memory accesses. For how > many of > > those M accesses we can statically infer its location given concrete > values > > for the g...

...ctured > languages (OpenCL, GLSL). The code includes a drop-in OpenCL driver > that > allows source-to-source OpenCL code transformations on existing OpenCL > applications. > The OpenCL backend has been under development for a while now and was > tested against the NVIDIA, AMD and Rodinia demo/benchmark suites with > recent NVIDIA/AMD drivers. Results for NVIDIA and AMD show, with few > exceptions, that the source-to-source-loop does not introduce any > performance penalty on the generated kernels (known exception: AES on > recent AMD drivers), > > However, kernel...

...enCL, GLSL). The code includes a drop-in OpenCL driver > > that > > allows source-to-source OpenCL code transformations on existing OpenCL > > applications. > > The OpenCL backend has been under development for a while now and was > > tested against the NVIDIA, AMD and Rodinia demo/benchmark suites with > > recent NVIDIA/AMD drivers. Results for NVIDIA and AMD show, with few > > exceptions, that the source-to-source-loop does not introduce any > > performance penalty on the generated kernels (known exception: AES on > > recent AMD drivers), > &...

...). The code includes a drop-in > > > OpenCL driver that allows source-to-source OpenCL code > > > transformations on existing OpenCL applications. > > > The OpenCL backend has been under development for a while now and > > > was tested against the NVIDIA, AMD and Rodinia demo/benchmark suites > > > with recent NVIDIA/AMD drivers. Results for NVIDIA and AMD show, > > > with few exceptions, that the source-to-source-loop does not > > > introduce any performance penalty on the generated kernels (known > > > exception: AES on recent...

...ixisting solution. ------------- Best regards, Alexey Bataev 13.03.2019 15:08, Doerfert, Johannes пишет: > Please consider reviewing the code for the proposed approach here: > https://reviews.llvm.org/D57460 > > Initial tests, e.g., on the nw (needleman-wunsch) benchmark in the > rodinia 3.1 benchmark suite, showed 30% improvement after SPMD mode was > enabled automatically. The code in nw is conceptually equivalent to the > first example in the "to_SPMD_mode.ll" test case that can be found here: > https://reviews.llvm.org/D57460#change-sBfg7kuN4Bid > > T...

...imental!) to this release as an example of an heterogeneous pocl device driver. Even though the OpenCL 1.2 standard is not yet implemented fully and it contains known bugs, we consider pocl ready for wider scale testing. The pocl 0.7 test suite compiles and runs most of the ViennaCL 1.3.1 examples,Rodinia 2.0.1 benchmarks, Parboil benchmarks, OpenCL Programming Guide book samples and the AMD APP SDK v2.8 OpenCL samples. Acknowledgements ---------------- We'd like to thank the Radio Implementation Research Team from Nokia Research Center which sponsored the development of this release. Much appr...

...ntains plenty of bug fixes, and provides several new OpenCL API implementations. We consider pocl ready for wider scale testing, although the OpenCL 1.2 standard is not yet fully implemented, and it contains known bugs. The pocl 0.8 test suite compiles and runs most of the ViennaCL 1.3.1 examples, Rodinia 2.0.1 benchmarks, Parboil benchmarks, OpenCL Programming Guide book samples, VexCL test cases, Luxmark v2.0, and most of the AMD APP SDK v2.8 OpenCL samples, among others. Links ----- Home page: http://pocl.sourceforge.net/ This announcement: http://pocl.sourceforge.net/pocl-0.8.html Chang...

...> Best regards, > Alexey Bataev > 13.03.2019 15:08, Doerfert, Johannes пишет: >> Please consider reviewing the code for the proposed approach here: >> https://reviews.llvm.org/D57460 >> >> Initial tests, e.g., on the nw (needleman-wunsch) benchmark in the >> rodinia 3.1 benchmark suite, showed 30% improvement after SPMD mode was >> enabled automatically. The code in nw is conceptually equivalent to the >> first example in the "to_SPMD_mode.ll" test case that can be found here: >> https://reviews.llvm.org/D57460#change-sBfg7kuN4Bid...

...t; 13.03.2019 15:08, Doerfert, Johannes пишет: >>>> Please consider reviewing the code for the proposed approach here: >>>> https://reviews.llvm.org/D57460 >>>> >>>> Initial tests, e.g., on the nw (needleman-wunsch) benchmark in the >>>> rodinia 3.1 benchmark suite, showed 30% improvement after SPMD mode was >>>> enabled automatically. The code in nw is conceptually equivalent to the >>>> first example in the "to_SPMD_mode.ll" test case that can be found here: >>>> https://reviews.llvm.org/D57...

...gt; 13.03.2019 15:08, Doerfert, Johannes пишет: >>>> Please consider reviewing the code for the proposed approach here: >>>> https://reviews.llvm.org/D57460 >>>> >>>> Initial tests, e.g., on the nw (needleman-wunsch) benchmark in the >>>> rodinia 3.1 benchmark suite, showed 30% improvement after SPMD mode was >>>> enabled automatically. The code in nw is conceptually equivalent to the >>>> first example in the "to_SPMD_mode.ll" test case that can be found here: >>>> https://reviews.llvm.org/D57...

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int...

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it