search for: nbody

I am trying to generate PTX code for 'nbody' sample program's kernel (nbody_kernel.cu) using clang/LLVM version 3.2. The nbody CUDA program is available in Nvidia's SDK. I am referring to https://github.com/jholewinski/llvm-ptx-samples project. Following are my commands, clang++ -O4 -S -I/usr/local/cuda/include -emit-llvm -...

...>> As part of my compute work I'm trying to get some TGSI compute >> code to work. The code from mesa/src/gallium/tests/trivial.c >> works. >> >> So now I'm trying to get a "native" tgsi kernel to run via >> clover, I'm using Francisco's nbody.c example for this: >> >> https://fedorapeople.org/~jwrdegoede/nbody.c >> >> Which does not work, at first I thought there was an issue >> with the setup of the input / output buffers, but that seems to >> work fine, and moreover I finally got the smart idea to l...

...> Sorry I only included a small bit of the program in my original mail > because I found the use of "MOV" instructions to load constants > suspicious, is that normal ? > > I've put a log with NV50_PROG_DEBUG=1 output here: > > https://fedorapeople.org/~jwrdegoede/nbody.log > > nvdisasm -b SM30 for the generated binary code is here: > > https://fedorapeople.org/~jwrdegoede/nbody.disasm > > There are already .tgsi, .hex and .bin files there if > you find those easier to use then the > NV50_PROG_DEBUG=1 output. > > >> >> On...

Hi all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this: https://fedorapeople.org/~jwrdegoede/nbody.c Which does not work, at first I thought there was an issue with the setup of the input / output buffers, but that seems to work fine, and moreover I finally got the smart idea to look in dmesg, which says: [ 9920.802435] nouveau 00...

Well, I tried the command line given by you and I get the following error clang++ nbody.kernel.cu -Xclang -fcuda-is-device -I/home/upitamba/llvm-3.2.src/tools/clang/test/SemaCUDA/ -Xclang -triple -Xclang nvptx64 -Xclang -target-cpu -Xclang sm_10 -S fatal error: error in backend: Cannot select: 0x334a870: v4f32 = NVPTXISD::MoveParam 0x334a770 [ORD=1] [ID=22] 0x334a770: v4f32 = Targe...

...e file. Where are you getting this file? From the CUDA toolkit? Since the error is in the back-end, can you just post the .ll or .bc file you are trying to compile? On Mon, Mar 18, 2013 at 12:42 AM, upit <uday_pitambare at yahoo.com> wrote: > I am trying to generate PTX code for 'nbody' sample program's kernel > (nbody_kernel.cu) using clang/LLVM version 3.2. The nbody CUDA program is > available in Nvidia's SDK. > > I am referring to https://github.com/jholewinski/llvm-ptx-samples project. > > Following are my commands, > > clang++ -O4 -S -I/u...

Please find the .ll attached below . Yes, I am using the cuda_runtime.h from the toolkit. nbody.kernel.ll <http://llvm.1065342.n5.nabble.com/file/n56048/nbody.kernel.ll> - Uday -- View this message in context: http://llvm.1065342.n5.nabble.com/UNREACHABLE-executed-error-while-trying-to-generate-PTX-tp56026p56048.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

...particular error is fixed in trunk, but with your code I'm now hitting a new issue. I'll get the fix in soon. On Fri, Mar 22, 2013 at 1:08 AM, upit <uday_pitambare at yahoo.com> wrote: > Well, I tried the command line given by you and I get the following error > > clang++ nbody.kernel.cu -Xclang -fcuda-is-device > -I/home/upitamba/llvm-3.2.src/tools/clang/test/SemaCUDA/ -Xclang -triple > -Xclang nvptx64 -Xclang -target-cpu -Xclang sm_10 -S > > fatal error: error in backend: Cannot select: 0x334a870: v4f32 = > NVPTXISD::MoveParam 0x334a770 [ORD=1] [ID=22] &g...

...es off executing into the ether? Sorry I only included a small bit of the program in my original mail because I found the use of "MOV" instructions to load constants suspicious, is that normal ? I've put a log with NV50_PROG_DEBUG=1 output here: https://fedorapeople.org/~jwrdegoede/nbody.log nvdisasm -b SM30 for the generated binary code is here: https://fedorapeople.org/~jwrdegoede/nbody.disasm There are already .tgsi, .hex and .bin files there if you find those easier to use then the NV50_PROG_DEBUG=1 output. > > On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirki...

...works fine on my GK107 [GeForce GT 740]. I think that for now I'll just focus on translating the tests from rc/gallium/tests/trivial/compute.c to opencl and getting the entire opencl -> llvm -> tgsi -> nouveau_compiler -> hardware chain to work that way. Still would be good to get nbody.c to work though. Regards, Hans > > Cheers, > > -ilia > > > > On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 15-12-15 20:04, Ilia Mirkin wrote: >>> >>> Also, where's the e...

...ded a small bit of the program in my original mail >> because I found the use of "MOV" instructions to load constants >> suspicious, is that normal ? >> >> I've put a log with NV50_PROG_DEBUG=1 output here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.log >> >> nvdisasm -b SM30 for the generated binary code is here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.disasm >> >> There are already .tgsi, .hex and .bin files there if >> you find those easier to use then the >> NV50_PROG_DEBUG=1 output....

..._ modifier from CUDA in Clang, define it like so: #define __constant__ __attribute__((address_space(2))) On Mon, Mar 18, 2013 at 6:31 PM, upit <uday_pitambare at yahoo.com> wrote: > Please find the .ll attached below . Yes, I am using the cuda_runtime.h > from > the toolkit. > nbody.kernel.ll > <http://llvm.1065342.n5.nabble.com/file/n56048/nbody.kernel.ll> > - Uday > > > > > -- > View this message in context: > http://llvm.1065342.n5.nabble.com/UNREACHABLE-executed-error-while-trying-to-generate-PTX-tp56026p56048.html > Sent from the LLVM -...

...rote: > Hi all, > > As part of my compute work I'm trying to get some TGSI compute > code to work. The code from mesa/src/gallium/tests/trivial.c > works. > > So now I'm trying to get a "native" tgsi kernel to run via > clover, I'm using Francisco's nbody.c example for this: > > https://fedorapeople.org/~jwrdegoede/nbody.c > > Which does not work, at first I thought there was an issue > with the setup of the input / output buffers, but that seems to > work fine, and moreover I finally got the smart idea to look > in dmesg, which...

OK. That helps. It does flash a warning though [DEVICE-C++] nbody.kernel.cpp nbody.kernel.cpp:29:9: warning: '__constant__' macro redefined #define __constant__ __attribute__((address_space(2))) ^ /opt/cuda/include/host_defines.h:183:9: note: previous definition is here #define __constant__ \ ^ 1 warning generated. Another question is Wh...

Not really. Clang does not have a way to annotate device vs. kernel functions in C/C++ mode. You're probably better off trying to use OpenCL or CUDA mode in clang. In the clang unit tests, there is a cuda.h header that provides very basic support for these keywords: tests/SemaCUDA/cuda.h If you compile as CUDA (use .cu extension, or "-x cuda") and use this header, you will have

Thanks a lot Justin, I will remove the toolkit header. Just one last question..(maybe ;) ) If I do away with toolkit headers it says unknown type name '__device__'. Does this function qualifier have an alternative ? or I can just do away with ? -- View this message in context: http://llvm.1065342.n5.nabble.com/UNREACHABLE-executed-error-while-trying-to-generate-PTX-tp56026p56093.html

On Wed, Mar 20, 2013 at 11:29 AM, upit <uday_pitambare at yahoo.com> wrote: > OK. That helps. > It does flash a warning though > > [DEVICE-C++] nbody.kernel.cpp > nbody.kernel.cpp:29:9: warning: '__constant__' macro redefined > #define __constant__ __attribute__((address_space(2))) > ^ > /opt/cuda/include/host_defines.h:183:9: note: previous definition is here > #define __constant__ \ > ^ > 1 warning...

....com/2vokmep > > ### hg_startup ### > Mem max: 7000.000 -> 7012.000: 1.0017x larger > Usage over time: http://tinyurl.com/3x4wneu > > ### iterative_count ### > Mem max: 9992.000 -> 9908.000: 1.0085x smaller > Usage over time: http://tinyurl.com/24dy7ql > > ### nbody ### > Mem max: 13552.000 -> 13240.000: 1.0236x smaller > Usage over time: http://tinyurl.com/23dstyu > > ### normal_startup ### > Mem max: 5380.000 -> 5396.000: 1.0030x larger > Usage over time: http://tinyurl.com/2fh7cmv > > ### nqueens ### > Mem max: 12832.000 -...

...0: 1.0033x smaller Usage over time: http://tinyurl.com/2vokmep ### hg_startup ### Mem max: 7000.000 -> 7012.000: 1.0017x larger Usage over time: http://tinyurl.com/3x4wneu ### iterative_count ### Mem max: 9992.000 -> 9908.000: 1.0085x smaller Usage over time: http://tinyurl.com/24dy7ql ### nbody ### Mem max: 13552.000 -> 13240.000: 1.0236x smaller Usage over time: http://tinyurl.com/23dstyu ### normal_startup ### Mem max: 5380.000 -> 5396.000: 1.0030x larger Usage over time: http://tinyurl.com/2fh7cmv ### nqueens ### Mem max: 12832.000 -> 12756.000: 1.0060x smaller Usage over ti...

...d at CGO'11: http://dx.doi.org/10.1109/CGO.2011.5764682 In contrast to Clover and pocl, we aimed at maximum performance before full support of the API (which simply requires more manpower than one PhD student). The driver was evaluated using benchmarks from the AMD APP SDK, e.g. Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT, ... Our measurements show that our driver outperforms both Intel's and AMD's CPU driver for almost all of the benchmarks. We plan to release both the vectorization library as well as the OpenCL driver under a BSD-style license, but there...