From don at codesourcery.com Thu Oct 8 21:50:42 2009 From: don at codesourcery.com (Don McCoy) Date: Thu, 08 Oct 2009 15:50:42 -0600 Subject: [patch] New example showing how to use Tensor subviews Message-ID: <4ACE5EB2.3070808@codesourcery.com> This example shows two ways to use a sub-matrix view of a Tensor, first as direct reference and secondly through a persistent subview that references the original view. Ok to commit? -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tensor_subview.changes URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tensor_subview.diff Type: text/x-patch Size: 1613 bytes Desc: not available URL: From stefan at codesourcery.com Thu Oct 8 22:23:06 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 08 Oct 2009 18:23:06 -0400 Subject: [vsipl++] [patch] New example showing how to use Tensor subviews In-Reply-To: <4ACE5EB2.3070808@codesourcery.com> References: <4ACE5EB2.3070808@codesourcery.com> Message-ID: <4ACE664A.8060503@codesourcery.com> On 10/08/2009 05:50 PM, Don McCoy wrote: > This example shows two ways to use a sub-matrix view of a Tensor, first > as direct reference and secondly through a persistent subview that > references the original view. > > Ok to commit? While I'm happy to see more documentation / examples, I have some minor issues: > Index: examples/tensor_subview.cpp > =================================================================== > --- examples/tensor_subview.cpp (revision 0) > +++ examples/tensor_subview.cpp (revision 0) I believe we should stop adding things directly to examples/. One of the yet-to-be-written chapters is an introduction about blocks and views, and this is what I believe your example fits nicely into. Thus I'd like to propose to put the above into examples/views/tensor_subview.cpp, i.a. make 'views/' a new subdirectory, dedicated to explaining the various view APIs. > +using namespace std; > +using namespace vsip; > +using namespace vsip_csl; I think we should also avoid to use namespace directives too freely, as that has the potential of creating name clashes or ambiguities. Notably, as soon as you use 'vsip' and 'vsip_csl', 'impl' becomes ambiguous... Other than that, I think your example is fine. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From don at codesourcery.com Thu Oct 8 23:02:32 2009 From: don at codesourcery.com (Don McCoy) Date: Thu, 08 Oct 2009 17:02:32 -0600 Subject: [vsipl++] [patch] New example showing how to use Tensor subviews In-Reply-To: <4ACE664A.8060503@codesourcery.com> References: <4ACE5EB2.3070808@codesourcery.com> <4ACE664A.8060503@codesourcery.com> Message-ID: <4ACE6F88.6060307@codesourcery.com> These are all good ideas. I've eliminated all namespace directives with the exception of 'vsip'. Note the need for 'using vsip_csl::operator<<' as a result. Is it possible to include that statement directly in vsip_csl/output.hpp? Or would it be considered unsafe to do it this way? The benefit would be that it avoids the obscure error message that results if the directive is left out. Otherwise, all feedback applied. Can you verify I made all the necessary makefile changes to include the new subdirectory? Thanks, -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tensor_subview2.changes URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tensor_subview2.diff Type: text/x-patch Size: 2824 bytes Desc: not available URL: From stefan at codesourcery.com Fri Oct 9 04:30:15 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 09 Oct 2009 00:30:15 -0400 Subject: [vsipl++] [patch] New example showing how to use Tensor subviews In-Reply-To: <4ACE6F88.6060307@codesourcery.com> References: <4ACE5EB2.3070808@codesourcery.com> <4ACE664A.8060503@codesourcery.com> <4ACE6F88.6060307@codesourcery.com> Message-ID: <4ACEBC57.6060500@codesourcery.com> On 10/08/2009 07:02 PM, Don McCoy wrote: > These are all good ideas. I've eliminated all namespace directives with > the exception of 'vsip'. Note the need for 'using vsip_csl::operator<<' > as a result. Is it possible to include that statement directly in > vsip_csl/output.hpp? Or would it be considered unsafe to do it this way? > The benefit would be that it avoids the obscure error message that > results if the directive is left out. Yeah, I understand and agree this is bad. I think what you are suggesting is a good idea. It only exposes the operator<<, nothing else. Thus it is as if we added it to vsip::, only that it comes from a non-standard header. Yes, I think that's fine, so please do what you suggest. > Otherwise, all feedback applied. Can you verify I made all the necessary > makefile changes to include the new subdirectory? This looks fine. Thanks ! Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From speed at square-enix.com Fri Oct 9 09:03:28 2009 From: speed at square-enix.com (Speed Erek) Date: Fri, 9 Oct 2009 18:03:28 +0900 Subject: num_processors() reporting the wrong number fo Processors Message-ID: <9DA8B24D50A0DE4589C1A4BD81A3E9806990D33FA7@JP-MX01.jp.co.square-enix.com> Hi, I'm running a parrallel vsip++ program on a Xenon with 2 processors and 8 cores. Installed is the light version of vsipl++ with no options to ./configure. In my program I print out the return value of num_processors() for verification purposes and it returns 1 instead of the 8 I might expect. I figure this is could be due to two reasons: 1. VSIPL++ lite doesn't support parallel features. It'd be nice if the differences in the lite version were specified somewhere but the problem is fixed once we get the commercial version. 2. During installation I was supposed to include an option to enable parallel support but I didn't and so it doesn't work. I didn't find anything in the "Getting Started" guide which mentioned enabling built-in parallel support (just external libraries like MPI) but if this is the case I would be ever grateful if someone could provide the correct options to use. Thanks, Erek -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at codesourcery.com Fri Oct 9 17:49:33 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 09 Oct 2009 13:49:33 -0400 Subject: [vsipl++] num_processors() reporting the wrong number fo Processors In-Reply-To: <9DA8B24D50A0DE4589C1A4BD81A3E9806990D33FA7@JP-MX01.jp.co.square-enix.com> References: <9DA8B24D50A0DE4589C1A4BD81A3E9806990D33FA7@JP-MX01.jp.co.square-enix.com> Message-ID: <4ACF77AD.7040607@codesourcery.com> On 10/09/2009 05:03 AM, Speed Erek wrote: > Hi, > > I'm running a parrallel vsip++ program on a Xenon with 2 processors and > 8 cores. Installed is the light version of vsipl++ with no options to > ./configure. In my program I print out the return value of > num_processors() for verification purposes and it returns 1 instead of > the 8 I might expect. Can you elaborate on what you mean by "running a parallel vsip++ program" ? Are you running it with mpirun ? > I figure this is could be due to two reasons: > > 1. VSIPL++ lite doesn't support parallel features. It'd be nice if the > differences in the lite version were specified somewhere but the problem > is fixed once we get the commercial version. That's a fair point. I believe the offered functionality (as far as the API is concerned) is the same, though the 'Lite' edition may not provide as many platform-specific optimizations, and thus run slower there. > 2. During installation I was supposed to include an option to enable > parallel support but I didn't and so it doesn't work. I didn't find > anything in the "Getting Started" guide which mentioned enabling > built-in parallel support (just external libraries like MPI) but if this > is the case I would be ever grateful if someone could provide the > correct options to use. You may enable parallel support by specifying --enable-parallel. By default, configure probes to find a suitable MPI installation. However, as you have requested an evaluation license recently, you will get a binary version which is configured and built with all the right flags, so you don't have to do any of this yourself. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From speed at square-enix.com Tue Oct 13 03:07:06 2009 From: speed at square-enix.com (Speed Erek) Date: Tue, 13 Oct 2009 12:07:06 +0900 Subject: [vsipl++] num_processors() reporting the wrong number fo Processors In-Reply-To: <4ACF77AD.7040607@codesourcery.com> References: <9DA8B24D50A0DE4589C1A4BD81A3E9806990D33FA7@JP-MX01.jp.co.square-enix.com> <4ACF77AD.7040607@codesourcery.com> Message-ID: <9DA8B24D50A0DE4589C1A4BD81A3E9806990D34078@JP-MX01.jp.co.square-enix.com> > -----Original Message----- > From: Stefan Seefeld [mailto:stefan at codesourcery.com] > Sent: Saturday, October 10, 2009 2:50 AM > To: vsipl++ at codesourcery.com > Subject: Re: [vsipl++] num_processors() reporting the wrong number fo > Processors > > On 10/09/2009 05:03 AM, Speed Erek wrote: > > Hi, > > > > I'm running a parrallel vsip++ program on a Xenon with 2 processors and > > 8 cores. Installed is the light version of vsipl++ with no options to > > ./configure. In my program I print out the return value of > > num_processors() for verification purposes and it returns 1 instead of > > the 8 I might expect. > > Can you elaborate on what you mean by "running a parallel vsip++ > program" ? Are you running it with mpirun ? There might be a bit of confusion here. I was thinking that you could use an external library for added efficiency but if you didn't then you would get some kind of built-in support and work a bit like OpenMP. (Straight from the command line.) In short, I thought if I used maps and ran the program then it would use multiple processors. I think I understand now that MPI or the like is required though. Thanks for the reply. From don at codesourcery.com Wed Oct 14 23:01:54 2009 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 Oct 2009 17:01:54 -0600 Subject: [patch] Make stream insertion operator easier to use Message-ID: <4AD65862.2070208@codesourcery.com> This adds a declaration that makes it ok to do this: std::cout << view << std::endl; Without a 'namespace' or 'using' declaration. Ok to commit once I add a Changelog entry? -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 -------------- next part -------------- A non-text attachment was scrubbed... Name: output.diff Type: text/x-patch Size: 417 bytes Desc: not available URL: From stefan at codesourcery.com Thu Oct 15 00:19:55 2009 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 14 Oct 2009 20:19:55 -0400 Subject: [vsipl++] [patch] Make stream insertion operator easier to use In-Reply-To: <4AD65862.2070208@codesourcery.com> References: <4AD65862.2070208@codesourcery.com> Message-ID: <4AD66AAB.1010200@codesourcery.com> On 10/14/2009 07:01 PM, Don McCoy wrote: > This adds a declaration that makes it ok to do this: > > std::cout << view << std::endl; > > Without a 'namespace' or 'using' declaration. > > Ok to commit once I add a Changelog entry? That looks good to me. Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From brian.j.loe at lmco.com Thu Oct 15 22:16:05 2009 From: brian.j.loe at lmco.com (Loe, Brian J) Date: Thu, 15 Oct 2009 16:16:05 -0600 Subject: FW: FW: GPU VSIPL++ Message-ID: <97FBBF7331C9C24CA5417C5CDE58434E01B2E567E8@HDXMSP7.us.lmco.com> I am trying to configure VSIPL++ with CUDA tools. We have already tried the GPU-VSIPL code from GTRI, but wanted to use CodeSourcery's VSIPL++. I had installed version 2.3 of the CUDA toolkit and a beta version of a video driver from NVIDIA for the GTRI GPU-VSIPL code. The attached e-mail was from an exchange that I had with Stefan Seefield in which he tried to help me troubleshoot a VSIPL++ installation with CUDA version 2.3. Since I was having no luck troubleshooting the configuration of VSIPL++ with version 2.3 CUDA toolkit, I removed it and the beta video driver and installed version 2.2 and Nvidia driver 185.18.14. (I also installed Atlas 8.3.) Following that I was able to configure VSIPL++ with the invocation $ ./configure --with-cuda --enable-fft=cuda I am also able to build and install the VSIPL++ library and build the code in the examples directory. However, when I try to execute example1, I get $ ./example1 FATAL: Module nvidia not found. NVIDIA: failed to load the NVIDIA kernel module. CUBLAS problem encountered (error 1) example1: src/vsip/opt/cuda/bindings.cpp:45: void vsip::impl::cuda::initialize(int&, char**&): Assertion `status == 0' failed. Aborted I get similar messages from the other example programs. I don't understand why example1 does not seem to find the video driver. Any ideas? -- Brian J. Loe, PhD Lockheed Martin Eagan, MN 651-456-2986 ________________________________________ From: Stefan Seefeld [stefan at codesourcery.com] Sent: Friday, October 09, 2009 2:49 PM To: Loe, Brian J; VSIPL++ Internal List Subject: Re: FW: GPU VSIPL++ On 10/09/2009 02:38 PM, Loe, Brian J wrote: > Could is be that this is a 64-bit system > > $ ls /usr/local/cuda/ > bin cudaprof doc include lib lib64 man open64 src > > The config.log says > > configure:11999: checking for cublas.h > configure:12020: g++ -c -g -O2 -I/usr/local/cuda/include conftest.cpp>&5 > configure:12027: $? = 0 > configure:12042: result: yes > configure:12059: checking for library containing cublasGetError > configure:12100: g++ -o conftest -g -O2 -I/usr/local/cuda/include -L/usr/local/cuda/lib conftest.cpp>&5 > /tmp/ccM1Wsvy.o: In function `main': > /opt/sourceryvsipl++-2.1/src/conftest.cpp:53: undefined reference to `cublasGetError' > collect2: ld returned 1 exit status > configure:12107: $? = 1 > > Wondering do I need a way to get the configure script to use -L/usr/local/cuda/lib64. Can it be as simple as renaming the directories? E.g. 'mv lib lib32; mv lib64 lib'? Ah. Yes, if your compiler builds 64-bit versions by default, and if your 64-bit CUDA libs are in lib64, renaming this to lib (or setting up a link) should solve it. (Make sure your LD_LIRBARY_PATH reflects that change.) Out of curiosity, how did you get /usr/local/cuda/lib64 ? Did you install CUDA manually there yourself ? I'm asking because if this is a location that other users may see, too, we should adjust our configuration to allow the CUDA library path to be set individually, instead of just offer a common 'CUDA prefix'. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From don at codesourcery.com Fri Oct 16 17:26:15 2009 From: don at codesourcery.com (Don McCoy) Date: Fri, 16 Oct 2009 11:26:15 -0600 Subject: [vsipl++] FW: FW: GPU VSIPL++ In-Reply-To: <97FBBF7331C9C24CA5417C5CDE58434E01B2E567E8@HDXMSP7.us.lmco.com> References: <97FBBF7331C9C24CA5417C5CDE58434E01B2E567E8@HDXMSP7.us.lmco.com> Message-ID: <4AD8ACB7.1020301@codesourcery.com> Loe, Brian J wrote: > I am also able to build and install the VSIPL++ library and build the code in the examples directory. > > However, when I try to execute example1, I get > > $ ./example1 > FATAL: Module nvidia not found. > NVIDIA: failed to load the NVIDIA kernel module. > CUBLAS problem encountered (error 1) > example1: src/vsip/opt/cuda/bindings.cpp:45: void vsip::impl::cuda::initialize(int&, char**&): Assertion `status == 0' failed. > Aborted > > It sounds as though there is a driver problem. Can you run one of the example programs from the SDK without this error? -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 From don at codesourcery.com Tue Oct 27 13:36:36 2009 From: don at codesourcery.com (Don McCoy) Date: Tue, 27 Oct 2009 07:36:36 -0600 Subject: [patch] Clarify solver documentation (mat_ntrans) Message-ID: <4AE6F764.7030506@codesourcery.com> This patch makes it more clear that mat_ntrans should be used with solve() when neither the transpose nor hermitian versions are desired. Ok to commit? -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ref_solv.changes URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ref_solv.diff Type: text/x-patch Size: 3296 bytes Desc: not available URL: From don at codesourcery.com Tue Oct 27 15:48:27 2009 From: don at codesourcery.com (Don McCoy) Date: Tue, 27 Oct 2009 09:48:27 -0600 Subject: [patch] Add descriptions for FIR class accessors Message-ID: <4AE7164B.2040300@codesourcery.com> This patch corrects a minor error in an example listed in the Reference Manual. It also provides more information on the accessors provided by the Fir<> class. Ok to commit? -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ref_fir.changes URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ref_fir.diff Type: text/x-patch Size: 1332 bytes Desc: not available URL: From brooks at codesourcery.com Tue Oct 27 15:55:18 2009 From: brooks at codesourcery.com (Brooks Moses) Date: Tue, 27 Oct 2009 08:55:18 -0700 Subject: [vsipl++] [patch] Clarify solver documentation (mat_ntrans) In-Reply-To: <4AE6F764.7030506@codesourcery.com> References: <4AE6F764.7030506@codesourcery.com> Message-ID: <4AE717E6.9000506@codesourcery.com> Don McCoy wrote, at 10/27/2009 6:36 AM: > This patch makes it more clear that mat_ntrans should be used with > solve() when neither the transpose nor hermitian versions are desired. > > Ok to commit? Yes. Thank you for quickly addressing this! - Brooks From brooks at codesourcery.com Tue Oct 27 16:00:15 2009 From: brooks at codesourcery.com (Brooks Moses) Date: Tue, 27 Oct 2009 09:00:15 -0700 Subject: [vsipl++] [patch] Add descriptions for FIR class accessors In-Reply-To: <4AE7164B.2040300@codesourcery.com> References: <4AE7164B.2040300@codesourcery.com> Message-ID: <4AE7190F.8090303@codesourcery.com> Don McCoy wrote, at 10/27/2009 8:48 AM: > This patch corrects a minor error in an example listed in the Reference > Manual. It also provides more information on the accessors provided by > the Fir<> class. > > Ok to commit? This looks good as well. Thanks, - Brooks From brooks at codesourcery.com Wed Oct 28 22:40:05 2009 From: brooks at codesourcery.com (Brooks Moses) Date: Wed, 28 Oct 2009 15:40:05 -0700 Subject: [vsipl++] [patch] Make stream insertion operator easier to use In-Reply-To: <4AD66AAB.1010200@codesourcery.com> References: <4AD65862.2070208@codesourcery.com> <4AD66AAB.1010200@codesourcery.com> Message-ID: <4AE8C845.6040308@codesourcery.com> Stefan Seefeld wrote, at 10/14/2009 5:19 PM: > On 10/14/2009 07:01 PM, Don McCoy wrote: >> This adds a declaration that makes it ok to do this: >> >> std::cout << view << std::endl; >> >> Without a 'namespace' or 'using' declaration. >> >> Ok to commit once I add a Changelog entry? > > That looks good to me. Ok with me as well. - Brooks From don at codesourcery.com Thu Oct 29 21:41:03 2009 From: don at codesourcery.com (Don McCoy) Date: Thu, 29 Oct 2009 15:41:03 -0600 Subject: [vsipl++] [patch] New example showing how to use Tensor subviews In-Reply-To: <4ACE5EB2.3070808@codesourcery.com> References: <4ACE5EB2.3070808@codesourcery.com> Message-ID: <4AEA0BEF.8030403@codesourcery.com> Don McCoy wrote: > This example shows two ways to use a sub-matrix view of a Tensor, > first as direct reference and secondly through a persistent subview > that references the original view. > Committed. -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712 From don at codesourcery.com Thu Oct 29 21:44:03 2009 From: don at codesourcery.com (Don McCoy) Date: Thu, 29 Oct 2009 15:44:03 -0600 Subject: [vsipl++] [patch] Make stream insertion operator easier to use In-Reply-To: <4AD65862.2070208@codesourcery.com> References: <4AD65862.2070208@codesourcery.com> Message-ID: <4AEA0CA3.8030904@codesourcery.com> Don McCoy wrote: > This adds a declaration that makes it ok to do this: > > std::cout << view << std::endl; > > Without a 'namespace' or 'using' declaration. > > Committed. -- Don McCoy CodeSourcery don at codesourcery.com (650) 331-3385 x712