From don at codesourcery.com Thu May 1 14:26:59 2008 From: don at codesourcery.com (Don McCoy) Date: Thu, 01 May 2008 08:26:59 -0600 Subject: [patch] Fixes for clapack options and blas 'integer' typedef Message-ID: <4819D333.2030405@codesourcery.com> As attached. Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clapack.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clapack.diff URL: From stefan at codesourcery.com Thu May 1 14:33:04 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 01 May 2008 10:33:04 -0400 Subject: [vsipl++] [patch] Fixes for clapack options and blas 'integer' typedef In-Reply-To: <4819D333.2030405@codesourcery.com> References: <4819D333.2030405@codesourcery.com> Message-ID: <4819D4A0.50306@codesourcery.com> Don McCoy wrote: > As attached. Ok to commit? Looks good. Please note that the clapack module is pulled in via svn:externals. Thus, this change can't go in as a single (atomic) checkin. In addition, clapack has its own ChangeLog.csl files, which is a better place to put the changelog note in. Jules, I notice that vendor/clapack has multiple ChangeLog.csl files, even though it is a single vendor library. What's the reason for this ? Can this be unified into a single toplevel vendor/clapack/ChangeLog.csl file ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From don at codesourcery.com Thu May 1 14:52:53 2008 From: don at codesourcery.com (Don McCoy) Date: Thu, 01 May 2008 08:52:53 -0600 Subject: [vsipl++] [patch] Fixes for clapack options and blas 'integer' typedef In-Reply-To: <4819D4A0.50306@codesourcery.com> References: <4819D333.2030405@codesourcery.com> <4819D4A0.50306@codesourcery.com> Message-ID: <4819D945.5010000@codesourcery.com> Stefan Seefeld wrote: > Don McCoy wrote: > >> As attached. Ok to commit? >> > > Looks good. Please note that the clapack module is pulled in via > svn:externals. Thus, this change can't go in as a single (atomic) > checkin. In addition, clapack has its own ChangeLog.csl files, which is > a better place to put the changelog note in. > Thanks for pointing that out. Committed. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From jules at codesourcery.com Thu May 1 16:20:23 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 01 May 2008 12:20:23 -0400 Subject: [vsipl++] [patch] Fixes for clapack options and blas 'integer' typedef In-Reply-To: <4819D4A0.50306@codesourcery.com> References: <4819D333.2030405@codesourcery.com> <4819D4A0.50306@codesourcery.com> Message-ID: <4819EDC7.7020303@codesourcery.com> > Jules, I notice that vendor/clapack has multiple ChangeLog.csl files, > even though it is a single vendor library. What's the reason for this ? > Can this be unified into a single toplevel vendor/clapack/ChangeLog.csl > file ? clapack is pulled in as three externals (into vendor/clapack/{SRC,F2CLIBS/libF77,blas/SRC}. A single ChangeLog in vendor/clapack couldn't also be in the vendor import directory. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Thu May 1 18:57:25 2008 From: don at codesourcery.com (Don McCoy) Date: Thu, 01 May 2008 12:57:25 -0600 Subject: [vsipl++] [patch] Fixes for clapack options and blas 'integer' typedef In-Reply-To: <4819D945.5010000@codesourcery.com> References: <4819D333.2030405@codesourcery.com> <4819D4A0.50306@codesourcery.com> <4819D945.5010000@codesourcery.com> Message-ID: <481A1295.9040601@codesourcery.com> This is a comment change only, to make all three copies of f2c.h consistent. Committed as obvious. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clapack2.diff URL: From stefan at codesourcery.com Mon May 5 20:52:49 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Mon, 05 May 2008 16:52:49 -0400 Subject: patch: robustify libpng check. Message-ID: <481F73A1.3080202@codesourcery.com> The attached patch robustifies the check for libpng by not only looking for the header, but also attempting to link. Previously we ran into a situation where libpng.h was found (as part of a 32-bit package, but the 64-bit version of the library then was not, resulting in a failure at compile-time, instead of simply disabling png-support at configure time. The patch is checked in as obvious. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From rutledge at ll.mit.edu Tue May 6 19:13:23 2008 From: rutledge at ll.mit.edu (Rutledge, Edward) Date: Tue, 6 May 2008 15:13:23 -0400 Subject: Problem compiling VSIPL++ Matrix code Message-ID: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> Hi, Using Sourcery VSIPL++ 1.4, I am trying to compile the following program but I get compile errors. Looking at the VSIPL++ spec, I think this is a valid program. Am I doing something wrong? #include #include int main(void) { vsip::vsipl prog(); const vsip::Matrix constM(2,2,99); vsip::scalar_i a = constM(0,0); // fails to compile vsip::Matrix m(2,2); m = vsip::scalar_i(99); // fails to compile return 0; } The compiler reports the following errors: % g++ -c Test.cc -I/tools/sourceryvsipl++/include Test.cc: In function 'int main()': Test.cc:9: error: passing 'const vsip::Matrix, vsip::Local_map> >' as 'this' argument of 'typename vsip::impl::Lvalue_factory_type::type::reference_type vsip::Matrix::operator()(vsip::index_type, vsip::index_type) [with T = int, Block = vsip::Dense<2u, int, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>]' discards qualifiers /tools/sourceryvsipl++/include/vsip/core/dispatch_assign.hpp: In function 'void vsip::impl::assign(DstBlock&, SrcBlock&) [with unsigned int D = 2u, DstBlock = vsip::Dense<2u, int, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>, SrcBlock = vsip::impl::Scalar_block<2u, int>]': /tools/sourceryvsipl++/include/vsip/matrix.hpp:259: instantiated from 'vsip::Matrix& vsip::Matrix::operator=(typename vsip::impl::Lvalue_factory_type::type::const_reference_type) [with T = int, Block = vsip::Dense<2u, int, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>]' Test.cc:12: instantiated from here /tools/sourceryvsipl++/include/vsip/core/dispatch_assign.hpp:290: error: incomplete type 'vsip::impl::Dispatch_assign<2u, vsip::Dense<2u, int, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>, vsip::impl::Scalar_block<2u, int>, vsip::impl::Tag_illegal_mix_of_local_and_global_in_assign>' used in nested name specifier Thanks, -Eddie ___________________________ Edward Rutledge MIT Lincoln Laboratory 244 Wood St Lexington, MA 02420 781-981-0274 rutledge at ll.mit.edu ___________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at codesourcery.com Tue May 6 20:40:28 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 06 May 2008 16:40:28 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> Message-ID: <4820C23C.1080202@codesourcery.com> Edward, Rutledge, Edward wrote: > Hi, > > Using Sourcery VSIPL++ 1.4, I am trying to compile the following program > but I get compile errors. Looking at the VSIPL++ spec, I think this is > a valid program. Am I doing something wrong? No you are not. I can confirm that this should work. Fortunately, there is a simple work-around: Insert an additional header on top: #include With that the compile error will go away. Obviously, we are going to fix this issue such that user code doesn't have to include that header if they don't otherwise need it. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From rutledge at ll.mit.edu Wed May 7 21:43:34 2008 From: rutledge at ll.mit.edu (Rutledge, Edward) Date: Wed, 7 May 2008 17:43:34 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <4820C23C.1080202@codesourcery.com> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> <4820C23C.1080202@codesourcery.com> Message-ID: <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> Stefan, That did fix one of the compile errors, but the other still occurs. Here is the code that fails to compile: #include #include #include int main(void) { vsip::vsipl prog(); const vsip::Matrix constM(2,2,99); vsip::scalar_i a = constM(0,0); // fails to compile return 0; } Here is the output from the compiler: % g++ -c Test.cc -I/tools/sourceryvsipl++/include Test.cc: In function 'int main()': Test.cc:9: error: passing 'const vsip::Matrix, vsip::Local_map> >' as 'this' argument of 'typename vsip::impl::Lvalue_factory_type::type::reference_type vsip::Matrix::operator()(vsip::index_type, vsip::index_type) [with T = int, Block = vsip::Dense<2u, int, vsip::tuple<0u, 1u, 2u>, vsip::Local_map>]' discards qualifiers Thanks for your help, -Eddie ___________________________ Edward Rutledge MIT Lincoln Laboratory 244 Wood St Lexington, MA 02420 781-981-0274 rutledge at ll.mit.edu ___________________________ -----Original Message----- From: Stefan Seefeld [mailto:stefan at codesourcery.com] Sent: Tuesday, May 06, 2008 4:40 PM To: Rutledge, Edward Cc: vsipl++ at codesourcery.com Subject: Re: [vsipl++] Problem compiling VSIPL++ Matrix code Edward, Rutledge, Edward wrote: > Hi, > > Using Sourcery VSIPL++ 1.4, I am trying to compile the following program > but I get compile errors. Looking at the VSIPL++ spec, I think this is > a valid program. Am I doing something wrong? No you are not. I can confirm that this should work. Fortunately, there is a simple work-around: Insert an additional header on top: #include With that the compile error will go away. Obviously, we are going to fix this issue such that user code doesn't have to include that header if they don't otherwise need it. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Wed May 7 22:32:02 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 07 May 2008 18:32:02 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> <4820C23C.1080202@codesourcery.com> <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> Message-ID: <48222DE2.4090602@codesourcery.com> Edward, Rutledge, Edward wrote: > Stefan, > That did fix one of the compile errors, but the other still occurs. > > > Here is the code that fails to compile: > > #include > #include > #include > > int main(void) > { > vsip::vsipl prog(); > const vsip::Matrix constM(2,2,99); > vsip::scalar_i a = constM(0,0); // fails to compile > return 0; > } I don't think the operator() notation you use above is officially supported, and in fact may not be supposed to work on const views. Can you use 'get()' instead ? vsip::scalar_i a = constM.get(0, 0); should work. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Thu May 8 02:20:11 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 07 May 2008 22:20:11 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> <4820C23C.1080202@codesourcery.com> <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> Message-ID: <4822635B.80808@codesourcery.com> Rutledge, Edward wrote: > vsip::vsipl prog(); > const vsip::Matrix constM(2,2,99); > vsip::scalar_i a = constM(0,0); // fails to compile > return 0; Another possible change would be to replace the 'const vsip::Matrix<...>' by 'vsip::const_Matrix<...>'. Note that VSIPL++ promotes passing view types (such as Matrix<>) by value, so the const qualifier isn't really very meaningful. Instead, use 'const_Matrix<>' to convey that its content is to be immutable. Using the above operator() notation on const_Matrix<> will work as expected, too. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From rutledge at ll.mit.edu Thu May 8 13:15:28 2008 From: rutledge at ll.mit.edu (Rutledge, Edward) Date: Thu, 8 May 2008 09:15:28 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <4822FB6E.40004@codesourcery.com> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> <4822FB6E.40004@codesourcery.com> Message-ID: <57F5948627B03042A29E70F4AABB446A62E3D6AAAA@LLE2K7-BE01.mitll.ad.local> Thanks for pointing that out. I will fix it. -Eddie ___________________________ Edward Rutledge MIT Lincoln Laboratory 244 Wood St Lexington, MA 02420 781-981-0274 rutledge at ll.mit.edu ___________________________ -----Original Message----- From: Stefan Seefeld [mailto:stefan at codesourcery.com] Sent: Thursday, May 08, 2008 9:09 AM To: Rutledge, Edward Cc: vsipl++ at codesourcery.com Subject: Re: [vsipl++] Problem compiling VSIPL++ Matrix code Edward, there is a small hard-to-see bug in this code that I ran into accidentally: Rutledge, Edward wrote: > int main(void) > > { > > vsip::vsipl prog(); While you probably want to create a 'vsip::vsipl' object here, what this actually does is declare a function returning 'vsip::vsipl' and taking no argument. (Remember the C++ rule: whenever it can be interpreted as a declaration, it is one.) This may lead to strange effects when you expect the library to be initialized while it actually isn't. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Thu May 8 13:09:02 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 08 May 2008 09:09:02 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> Message-ID: <4822FB6E.40004@codesourcery.com> Edward, there is a small hard-to-see bug in this code that I ran into accidentally: Rutledge, Edward wrote: > int main(void) > > { > > vsip::vsipl prog(); While you probably want to create a 'vsip::vsipl' object here, what this actually does is declare a function returning 'vsip::vsipl' and taking no argument. (Remember the C++ rule: whenever it can be interpreted as a declaration, it is one.) This may lead to strange effects when you expect the library to be initialized while it actually isn't. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From rutledge at ll.mit.edu Thu May 8 12:53:22 2008 From: rutledge at ll.mit.edu (Rutledge, Edward) Date: Thu, 8 May 2008 08:53:22 -0400 Subject: [vsipl++] Problem compiling VSIPL++ Matrix code In-Reply-To: <4822635B.80808@codesourcery.com> References: <57F5948627B03042A29E70F4AABB446A62E3D6A8B2@LLE2K7-BE01.mitll.ad.local> <4820C23C.1080202@codesourcery.com> <57F5948627B03042A29E70F4AABB446A62E3D6AA5A@LLE2K7-BE01.mitll.ad.local> <4822635B.80808@codesourcery.com> Message-ID: <57F5948627B03042A29E70F4AABB446A62E3D6AA9E@LLE2K7-BE01.mitll.ad.local> I will do that. Thanks for your help. -Eddie ___________________________ Edward Rutledge MIT Lincoln Laboratory 244 Wood St Lexington, MA 02420 781-981-0274 rutledge at ll.mit.edu ___________________________ -----Original Message----- From: Stefan Seefeld [mailto:stefan at codesourcery.com] Sent: Wednesday, May 07, 2008 10:20 PM To: Rutledge, Edward Cc: vsipl++ at codesourcery.com Subject: Re: [vsipl++] Problem compiling VSIPL++ Matrix code Rutledge, Edward wrote: > vsip::vsipl prog(); > const vsip::Matrix constM(2,2,99); > vsip::scalar_i a = constM(0,0); // fails to compile > return 0; Another possible change would be to replace the 'const vsip::Matrix<...>' by 'vsip::const_Matrix<...>'. Note that VSIPL++ promotes passing view types (such as Matrix<>) by value, so the const qualifier isn't really very meaningful. Instead, use 'const_Matrix<>' to convey that its content is to be immutable. Using the above operator() notation on const_Matrix<> will work as expected, too. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From don at codesourcery.com Tue May 13 17:26:05 2008 From: don at codesourcery.com (Don McCoy) Date: Tue, 13 May 2008 11:26:05 -0600 Subject: [patch] Fix for multiple initialization of ALF Message-ID: <4829CF2D.5020305@codesourcery.com> This patch fixes a problem when using the Cell/B.E. Math Library (CML), in that ALF was being initialized twice. The default behavior is preserved. The conditional VSIP_IMPL_HAVE_CML must be defined in order to use CML's initialization and finalization methods. Committed after approval off-list. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmlalf.diff URL: From don at codesourcery.com Tue May 13 21:42:38 2008 From: don at codesourcery.com (Don McCoy) Date: Tue, 13 May 2008 15:42:38 -0600 Subject: [patch] Matrix product 'backend' for CML Message-ID: <482A0B4E.3070004@codesourcery.com> This patch adds support for matrix products using the Cell/B.E. Math Library (CML). Note there is a new example demonstrating the prod() function for both scalar and complex values. This was tested with both interleaved-complex and split-complex layouts. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.diff URL: From jules at codesourcery.com Wed May 14 12:22:56 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 14 May 2008 08:22:56 -0400 Subject: [patch] Share ALF w/CML; Fix vmul_c kernel Message-ID: <482AD9A0.7090402@codesourcery.com> This patch initializes VSIPL++'s ALF handle from CML (CML patch required) so that VSIPL++'s kernels can work. It also rehabilitates the VSIPL++ interleaved complex vmul kernel. Next step is to disable VSIPL++ and CML ALF caching, so that VSIPL++ and CML do not get in each other's way. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cml-alf.diff URL: From stefan at codesourcery.com Wed May 14 12:40:07 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 14 May 2008 08:40:07 -0400 Subject: [vsipl++] [patch] Share ALF w/CML; Fix vmul_c kernel In-Reply-To: <482AD9A0.7090402@codesourcery.com> References: <482AD9A0.7090402@codesourcery.com> Message-ID: <482ADDA7.4030406@codesourcery.com> Jules Bergmann wrote: > This patch initializes VSIPL++'s ALF handle from CML (CML patch > required) so that VSIPL++'s kernels can work. It also rehabilitates the > VSIPL++ interleaved complex vmul kernel. > > Next step is to disable VSIPL++ and CML ALF caching, so that VSIPL++ and > CML do not get in each other's way. > #ifdef VSIP_IMPL_HAVE_CML > cml_init(); > + (void)num_accelerators; > + alf_ = cml_impl_alf_handle(); > + num_accelerators_ = query(ALF_QUERY_NUM_ACCEL); > #else > int status = alf_init(0, &alf_); > assert(status >= 0); > - if (num_accelerators) > - { > - set_num_accelerators(num_accelerators); > - assert(status >= 0); > - } > + > + set_num_accelerators(num_accelerators); > #endif Shouldn't we pass the 'num_accelerators' argument down to cml_init() ? Otherwise there is no way to mandate how many SPUs to use from SV++. Or am I missing something ? > +++ src/vsip/opt/cbe/spu/GNUmakefile.inc.in (working copy) > @@ -34,6 +34,8 @@ > > spe_kernels := lib/svpp_kernels.so > > +libs += $(spe_kernels) > + > CC_SPU := @CC_SPU@ > CXX_SPU := @CXX_SPU@ > EMBED_SPU := @EMBED_SPU@ > @@ -112,6 +114,7 @@ > -include src/vsip/opt/cbe/alf/src/spu/GNUmakefile.inc > I just noticed this inclusion, which I missed to remove in my previous patch. (The '-' at the beginning makes 'make' ignore the failure, so we didn't see it.) Can you please remove this line when you commit the patch ? The alf/ subdirectory doesn't exist any more... The patch looks good otherwise. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Wed May 14 13:25:11 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 14 May 2008 09:25:11 -0400 Subject: [vsipl++] [patch] Share ALF w/CML; Fix vmul_c kernel In-Reply-To: <482ADDA7.4030406@codesourcery.com> References: <482AD9A0.7090402@codesourcery.com> <482ADDA7.4030406@codesourcery.com> Message-ID: <482AE837.3040405@codesourcery.com> > > Shouldn't we pass the 'num_accelerators' argument down to cml_init() ? > Otherwise there is no way to mandate how many SPUs to use from SV++. Or > am I missing something ? Yes definitely! I was thinking of a FIXME to that effect. >> -include src/vsip/opt/cbe/alf/src/spu/GNUmakefile.inc >> > > I just noticed this inclusion, which I missed to remove in my previous > patch. (The '-' at the beginning makes 'make' ignore the failure, so we > didn't see it.) > Can you please remove this line when you commit the patch ? The alf/ > subdirectory doesn't exist any more. Yes, will do. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Wed May 14 15:14:17 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 14 May 2008 11:14:17 -0400 Subject: [vsipl++] [patch] Share ALF w/CML; Fix vmul_c kernel In-Reply-To: <482AE837.3040405@codesourcery.com> References: <482AD9A0.7090402@codesourcery.com> <482ADDA7.4030406@codesourcery.com> <482AE837.3040405@codesourcery.com> Message-ID: <482B01C9.6070804@codesourcery.com> Jules Bergmann wrote: > >> >> Shouldn't we pass the 'num_accelerators' argument down to cml_init() ? >> Otherwise there is no way to mandate how many SPUs to use from SV++. >> Or am I missing something ? > > Yes definitely! I was thinking of a FIXME to that effect. Applied as attached. Num_accelerators now gets passed to cml. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cml-alf.diff URL: From stefan at codesourcery.com Wed May 14 16:15:37 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 14 May 2008 12:15:37 -0400 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482A0B4E.3070004@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> Message-ID: <482B1029.3050807@codesourcery.com> Don McCoy wrote: > This patch adds support for matrix products using the Cell/B.E. Math > Library (CML). > > Note there is a new example demonstrating the prod() function for both > scalar and complex values. This was tested with both > interleaved-complex and split-complex layouts. This patch includes a 'Cml_traits' template that's equivalent to Type_equal::type, float>. If it is going to stay this simple, I would prefer not to introduce this 'Cml_traits' for it. On the other hand, you mentioned in another mail you were going to also check for split vs. interleaved there, so it may grow a little. I'm not yet convinced that such a generic Cml_traits template is useful, though, since availability of some (type, layout) may depend on the actual operation. Other than that, the patch looks good. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From don at codesourcery.com Wed May 14 20:52:00 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 May 2008 14:52:00 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B1029.3050807@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> Message-ID: <482B50F0.1010103@codesourcery.com> Stefan Seefeld wrote: > On the other hand, you mentioned in another mail you were going to also > check for split vs. interleaved there, so it may grow a little. I'm not > yet convinced that such a generic Cml_traits template is useful, though, > since availability of some (type, layout) may depend on the actual > operation. > > Other than that, the patch looks good. > I changed the parameter to accept the block type rather than the value_type for the block. The advantage here is that it centralizes the check for the correct data type, if nothing else. Later, we may add an operation type parameter to grant exceptions or exclusions, say if a particular function does not support split-complex for example. Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.diff URL: From don at codesourcery.com Wed May 14 21:18:56 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 May 2008 15:18:56 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B50F0.1010103@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> Message-ID: <482B5740.5020805@codesourcery.com> Don McCoy wrote: > I changed the parameter to accept the block type rather than the > value_type for the block. The advantage here is that it centralizes the > ... > One minor change: it now checks all three blocks, as suggested off list. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.diff URL: From jules at codesourcery.com Wed May 14 21:35:07 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 14 May 2008 17:35:07 -0400 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B5740.5020805@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> Message-ID: <482B5B0B.3040408@codesourcery.com> Don McCoy wrote: > Don McCoy wrote: >> I changed the parameter to accept the block type rather than the >> value_type for the block. The advantage here is that it centralizes the >> ... >> > One minor change: it now checks all three blocks, as suggested off list. Don, This looks good to me. I have a couple of minor comments below, otherwise, please check it in. thanks, -- Jules > +template + typename Block1, > + typename Block2> > +struct Evaluator, > + Cml_tag> > +{ > + typedef typename Block0::value_type T; > + typedef typename Block_layout::order_type order0_type; > + typedef typename Block_layout::order_type order1_type; > + typedef typename Block_layout::order_type order2_type; > + > + static bool const ct_valid = > + // check that CML supports this data type and/or layout > + impl::cml::Cml_supports_block::valid && > + impl::cml::Cml_supports_block::valid && > + impl::cml::Cml_supports_block::valid && > + // check that all data types are equal > + Type_equal::value && > + Type_equal::value && > + // check that the layout is row-major > + Type_equal::value && > + Type_equal::value && > + Type_equal::value && > + // check that direct access is supported > + Ext_data_cost::value == 0 && > + Ext_data_cost::value == 0 && > + Ext_data_cost::value == 0; You should also check that all three blocks have the same split/interleave format (using Is_split_block). Otherwise, this would try to handle a product between a split-complex and interleaved-complex block. > +// This version is for split complex only. > + > +#define VSIP_IMPL_CML_ZMPROD(T, FCN) \ > +inline void \ > +mprod( \ > + std::pair a, int lda, \ > + std::pair b, int ldb, \ > + std::pair z, int ldz, \ Its a minor point, but I was expecting to see 'std::pair'. I realize you pass 'T=float*' so it works out. For consistentency with the other macro I would suggest putting the '*' in the macro and passing 'T=float'. > +VSIP_IMPL_CML_ZMPROD(float*, cml_zmprod1_f) > +#undef VSIP_IMPL_CML_ZMPROD -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Wed May 14 23:40:53 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 14 May 2008 19:40:53 -0400 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B5B0B.3040408@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> <482B5B0B.3040408@codesourcery.com> Message-ID: <482B7885.9050708@codesourcery.com> Don, > You should also check that all three blocks have the same > split/interleave format (using Is_split_block). Otherwise, this would > try to handle a product between a split-complex and > interleaved-complex block. > Such a check might look like Is_split_block::value == Is_split_block::value && Is_split_block::value == Is_split_block::value && The danger of comparing Block_layout::complex_type directly is that scalar blocks actually have a complex format, but it doesn't mean anything. If two scalar blocks happened to have different complex formats, ct_valid would be false. It is an unlikely event, but using Is_split_block makes it an impossible event. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Thu May 15 00:52:38 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 May 2008 18:52:38 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B7885.9050708@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> <482B5B0B.3040408@codesourcery.com> <482B7885.9050708@codesourcery.com> Message-ID: <482B8956.4040400@codesourcery.com> Jules Bergmann wrote: > Such a check might look like > > Is_split_block::value == Is_split_block::value && > Is_split_block::value == Is_split_block::value && > > The danger of comparing Block_layout::complex_type directly is > that scalar blocks actually have a complex format, but it doesn't mean > anything. If two scalar blocks happened to have different complex > formats, ct_valid would be false. It is an unlikely event, but using > Is_split_block makes it an impossible event. > > Such a check will work only if it is performed on an evaluator that only handles complex types, or that otherwise has some condition excluding the case of one of those blocks being a scalar type (float in this case). If I only do the above and the format is interleaved, then blocks having either scalar or complex values will return false, allowing ct_valid to be true. But I see what you mean. My method was no good either, due to what you said about scalar blocks having an (invalid) complex type. I'd wondered about this. Thanks, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From don at codesourcery.com Thu May 15 01:01:28 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 May 2008 19:01:28 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B8956.4040400@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> <482B5B0B.3040408@codesourcery.com> <482B7885.9050708@codesourcery.com> <482B8956.4040400@codesourcery.com> Message-ID: <482B8B68.1020807@codesourcery.com> Don McCoy wrote: > Such a check will work only if it is performed on an evaluator that only > handles complex types, or that otherwise has some condition excluding > ... > Nevermind. I was not thinking clearly. Stefan pointed out that the value_types also are checked, so it is not a problem as I first thought. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From don at codesourcery.com Thu May 15 01:18:34 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 14 May 2008 19:18:34 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B5B0B.3040408@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> <482B5B0B.3040408@codesourcery.com> Message-ID: <482B8F6A.2070404@codesourcery.com> Jules Bergmann wrote: > This looks good to me. I have a couple of minor comments below, > otherwise, please check it in. > Committed as attached. Thank you everyone for the feedback. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp1.diff URL: From don at codesourcery.com Sat May 17 23:27:41 2008 From: don at codesourcery.com (Don McCoy) Date: Sat, 17 May 2008 17:27:41 -0600 Subject: [vsipl++] [patch] Matrix product 'backend' for CML In-Reply-To: <482B8F6A.2070404@codesourcery.com> References: <482A0B4E.3070004@codesourcery.com> <482B1029.3050807@codesourcery.com> <482B50F0.1010103@codesourcery.com> <482B5740.5020805@codesourcery.com> <482B5B0B.3040408@codesourcery.com> <482B8F6A.2070404@codesourcery.com> Message-ID: <482F69ED.1010204@codesourcery.com> Don McCoy wrote: > Index: examples/mprod.cpp > =================================================================== > --- examples/mprod.cpp (revision 0) > +++ examples/mprod.cpp (revision 0) > ... > + { > + typedef vsip::scalar_f T; > + typedef vsip::cscalar_f CT; > + Matrix a(5, 4, T(2)); > + Matrix b(4, 3, CT(3)); > + Matrix c(5, 3, CT()); > + > + c = prod(a, b); > + > + std::cout << "c = " << std::endl << c << std::endl; > + } > + > + return 0; > +} > I removed this test case from the example. It was left in there unintentionally. Committed as obvious. -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 From don at codesourcery.com Tue May 20 17:55:14 2008 From: don at codesourcery.com (Don McCoy) Date: Tue, 20 May 2008 11:55:14 -0600 Subject: [patch] matrix transpose products using CML Message-ID: <48331082.5040301@codesourcery.com> As attached. Note the expanded test coverage using dimension orderings. This is due to the fact that for row-major matrices 'r' and 'a' r = prodt(a, b) // if 'b' is row-major is equivalent to r = prod(a, b) // if 'b' is col-major Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp2.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp2.diff URL: From jules at codesourcery.com Tue May 20 19:57:38 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 20 May 2008 15:57:38 -0400 Subject: [vsipl++] [patch] matrix transpose products using CML In-Reply-To: <48331082.5040301@codesourcery.com> References: <48331082.5040301@codesourcery.com> Message-ID: <48332D32.9080304@codesourcery.com> Don McCoy wrote: > As attached. Note the expanded test coverage using dimension > orderings. This is due to the fact that for row-major matrices 'r' and 'a' > > r = prodt(a, b) // if 'b' is row-major > > is equivalent to > > r = prod(a, b) // if 'b' is col-major > > > Ok to commit? Don, this looks good, please check it in. thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Thu May 22 23:07:01 2008 From: don at codesourcery.com (Don McCoy) Date: Thu, 22 May 2008 17:07:01 -0600 Subject: [patch] Split matrix-product tests into multiple, smaller modules Message-ID: <4835FC95.8080402@codesourcery.com> As attached. The test coverage is the same. Now that it is split the need for VSIP_IMPL_TEST_LEVEL no longer exists, so it has been removed (meaning all tests are always run). Ok to commit? Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mp_tests.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mp_tests.diff URL: From don at codesourcery.com Fri May 23 07:52:55 2008 From: don at codesourcery.com (Don McCoy) Date: Fri, 23 May 2008 01:52:55 -0600 Subject: [patch] conjugate and hermitian products using CML Message-ID: <483677D7.10802@codesourcery.com> This patch adds backend support for conjugate and hermitian products for both interleaved- and split-complex storage. It also corrects a bug in prodh related to the return matrix size identical to the one found for prodt(). The test for prodh was calling prod(a, herm(b)) instead of prodh(a, b), which allowed this bug to go undetected. Similarly for prodj, which was also fixed. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp3.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp3.diff URL: From jules at codesourcery.com Fri May 23 11:19:31 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 23 May 2008 07:19:31 -0400 Subject: [vsipl++] [patch] Split matrix-product tests into multiple, smaller modules In-Reply-To: <4835FC95.8080402@codesourcery.com> References: <4835FC95.8080402@codesourcery.com> Message-ID: <4836A843.4050801@codesourcery.com> Don McCoy wrote: > As attached. The test coverage is the same. Now that it is split the > need for VSIP_IMPL_TEST_LEVEL no longer exists, so it has been removed > (meaning all tests are always run). > > Ok to commit? Don, This looks good, please commit. thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Fri May 23 11:22:59 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 23 May 2008 07:22:59 -0400 Subject: [vsipl++] [patch] conjugate and hermitian products using CML In-Reply-To: <483677D7.10802@codesourcery.com> References: <483677D7.10802@codesourcery.com> Message-ID: <4836A913.4000301@codesourcery.com> Don McCoy wrote: > This patch adds backend support for conjugate and hermitian products for > both interleaved- and split-complex storage. > > It also corrects a bug in prodh related to the return matrix size > identical to the one found for prodt(). The test for prodh was calling > prod(a, herm(b)) instead of prodh(a, b), which allowed this bug to go > undetected. Similarly for prodj, which was also fixed. Don, this patch looks good, please check it in. thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Sat May 24 19:21:20 2008 From: don at codesourcery.com (Don McCoy) Date: Sat, 24 May 2008 13:21:20 -0600 Subject: [patch] matrix-vector and vector-matrix product dispatch to CML Message-ID: <48386AB0.2030707@codesourcery.com> This patch required adding a new pair of tests to the existing matrix-vector product tests to cover cases of non-unit strides allowed by CML. Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp4.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp4.diff URL: From don at codesourcery.com Tue May 27 22:16:04 2008 From: don at codesourcery.com (Don McCoy) Date: Tue, 27 May 2008 16:16:04 -0600 Subject: [vsipl++] [patch] matrix-vector and vector-matrix product dispatch to CML In-Reply-To: <48386AB0.2030707@codesourcery.com> References: <48386AB0.2030707@codesourcery.com> Message-ID: <483C8824.5000004@codesourcery.com> Don McCoy wrote: > This patch required adding a new pair of tests to the existing > matrix-vector product tests to cover cases of non-unit strides allowed > by CML. > > Bindings for split-complex versions were omitted from the previous version of this patch. Ok to commit now? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp4b.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmp4b.diff URL: From jules at codesourcery.com Wed May 28 15:27:08 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 28 May 2008 11:27:08 -0400 Subject: [patch] Kernel updates Message-ID: <483D79CC.9060804@codesourcery.com> This patch updates the remaining VSIPL++ kernels to use ALF 3.0 and CML where possible. This removes the dependency on libfft_example from the SDK, removes the specialized split FFT routines, and pushes twiddle computation into the kernels. This also requires a minor CML patch, which I'll post separately. Ok to apply? -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: kernel.diff URL: From stefan at codesourcery.com Wed May 28 17:31:39 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 28 May 2008 13:31:39 -0400 Subject: [vsipl++] [patch] Kernel updates In-Reply-To: <483D79CC.9060804@codesourcery.com> References: <483D79CC.9060804@codesourcery.com> Message-ID: <483D96FB.8030301@codesourcery.com> Jules Bergmann wrote: > This patch updates the remaining VSIPL++ kernels to use ALF 3.0 and CML > where possible. This removes the dependency on libfft_example from the > SDK, removes the specialized split FFT routines, and pushes twiddle > computation into the kernels. > > This also requires a minor CML patch, which I'll post separately. > > Ok to apply? Jules, I have a single (minor) issue: > + * src/vsip/opt/cbe/spu/alf_pwarp_ub.cpp: Move ALF decls to > + alf_decl.hpp. Add missing argument to kernel. > + * src/vsip/opt/ceb/spu/alf_decls.hpp: New file, decls for functions > + expected by ALF. I don't quite understand the purpose of this split. Do you propose we adhere to the convention of naming these functions always 'input', 'output', and 'kernel' ? The only reason ALF expects those names is because you refer to them in the ALF_ACCEL_EXPORT_API macros, and it would have been enough to put an 'extern "C"' linkage spec in front of those function definitions, no matter how they are actually named. The patch looks good otherwise. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Wed May 28 17:48:14 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 28 May 2008 13:48:14 -0400 Subject: [vsipl++] [patch] Kernel updates In-Reply-To: <483D96FB.8030301@codesourcery.com> References: <483D79CC.9060804@codesourcery.com> <483D96FB.8030301@codesourcery.com> Message-ID: <483D9ADE.60202@codesourcery.com> Stefan, > I have a single (minor) issue: > >> + * src/vsip/opt/cbe/spu/alf_pwarp_ub.cpp: Move ALF decls to >> + alf_decl.hpp. Add missing argument to kernel. >> + * src/vsip/opt/ceb/spu/alf_decls.hpp: New file, decls for functions >> + expected by ALF. > > I don't quite understand the purpose of this split. Do you propose we > adhere to the convention of naming these functions always 'input', > 'output', and 'kernel' ? The only reason ALF expects those names is > because you refer to them in the ALF_ACCEL_EXPORT_API macros, and it > would have been enough to put an 'extern "C"' linkage spec in front of > those function definitions, no matter how they are actually named. The main intent was to prevent the 23 lines of declaration having to be replicated in every C++ kernel. It does however require following a naming convention for the routines. I didn't see that as a bad thing though. Do you think it will create a problem? It's sort of a moot point right now, as C++ kernels don't work with ALF 3.0. > > The patch looks good otherwise. Thanks! -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Thu May 29 13:38:48 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 29 May 2008 09:38:48 -0400 Subject: [vsipl++] [patch] Kernel updates In-Reply-To: <483D9ADE.60202@codesourcery.com> References: <483D79CC.9060804@codesourcery.com> <483D96FB.8030301@codesourcery.com> <483D9ADE.60202@codesourcery.com> Message-ID: <483EB1E8.104@codesourcery.com> Jules Bergmann wrote: > Stefan, > >> I have a single (minor) issue: >> >>> + * src/vsip/opt/cbe/spu/alf_pwarp_ub.cpp: Move ALF decls to >>> + alf_decl.hpp. Add missing argument to kernel. >>> + * src/vsip/opt/ceb/spu/alf_decls.hpp: New file, decls for functions >>> + expected by ALF. >> >> I don't quite understand the purpose of this split. Do you propose we >> adhere to the convention of naming these functions always 'input', >> 'output', and 'kernel' ? The only reason ALF expects those names is >> because you refer to them in the ALF_ACCEL_EXPORT_API macros, and it >> would have been enough to put an 'extern "C"' linkage spec in front of >> those function definitions, no matter how they are actually named. > > The main intent was to prevent the 23 lines of declaration having to be > replicated in every C++ kernel. It does however require following a > naming convention for the routines. I didn't see that as a bad thing > though. Do you think it will create a problem? My mistake, thanks for catching this! I saw the forward decls and assumed they were necessary, but they weren't. Changed as suggested, patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Thu May 29 14:56:51 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 29 May 2008 10:56:51 -0400 Subject: [vsipl++] [patch] matrix-vector and vector-matrix product dispatch to CML In-Reply-To: <483C8824.5000004@codesourcery.com> References: <48386AB0.2030707@codesourcery.com> <483C8824.5000004@codesourcery.com> Message-ID: <483EC433.7040606@codesourcery.com> Don McCoy wrote: > Don McCoy wrote: >> This patch required adding a new pair of tests to the existing >> matrix-vector product tests to cover cases of non-unit strides allowed >> by CML. >> >> > Bindings for split-complex versions were omitted from the previous > version of this patch. > > Ok to commit now? Don, I have a couple of minor nit-picks below with unused typedefs, but otherwise this looks good, please check it in. thanks, -- Jules > +/// CML evaluator for matrix-vector products > + > +template + typename Block1, > + typename Block2> > +struct Evaluator, > + Cml_tag> > +{ > + typedef typename Block0::value_type T; > + typedef typename Block_layout::order_type order0_type; > + typedef typename Block_layout::order_type order1_type; > + typedef typename Block_layout::order_type order2_type; order0_type and order2_type aren't used. > +/// CML evaluator for vector-matrix products > + > +template + typename Block1, > + typename Block2> > +struct Evaluator, > + Cml_tag> > +{ > + typedef typename Block0::value_type T; > + typedef typename Block_layout::order_type order0_type; > + typedef typename Block_layout::order_type order1_type; > + typedef typename Block_layout::order_type order2_type; order0_type and order1_type aren't used -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From brooks at codesourcery.com Thu May 29 23:35:21 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Thu, 29 May 2008 16:35:21 -0700 Subject: [vsipl++] [patch] Kernel updates In-Reply-To: <483D9ADE.60202@codesourcery.com> References: <483D79CC.9060804@codesourcery.com> <483D96FB.8030301@codesourcery.com> <483D9ADE.60202@codesourcery.com> Message-ID: <483F3DB9.9070102@codesourcery.com> Jules Bergmann wrote, at 5/28/2008 10:48 AM: > Stefan, >> I don't quite understand the purpose of this split. Do you propose we >> adhere to the convention of naming these functions always 'input', >> 'output', and 'kernel' ? The only reason ALF expects those names is >> because you refer to them in the ALF_ACCEL_EXPORT_API macros, and it >> would have been enough to put an 'extern "C"' linkage spec in front of >> those function definitions, no matter how they are actually named. > > The main intent was to prevent the 23 lines of declaration having to be > replicated in every C++ kernel. It does however require following a > naming convention for the routines. I didn't see that as a bad thing > though. Do you think it will create a problem? > > It's sort of a moot point right now, as C++ kernels don't work with ALF 3.0. */me looks at alf_functions.cpp in the SBIR demo code* */me is rather confused* As far as I can tell, C++ kernels seem to work fine with ALF 3.0, so long as the relevant functions (and the ALF macro stuff at the end) are wrapped in an 'extern "C"' block. - Brooks From stefan at codesourcery.com Fri May 30 05:33:57 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 30 May 2008 01:33:57 -0400 Subject: patch: enable/disable fftwf, fftw, and fftwl individually Message-ID: <483F91C5.5060701@codesourcery.com> The attached patch probes at configure-time for those three libraries, defines VSIP_IMPL_FFTW3_HAVE_{FLOAT, DOUBLE, LONG_DOUBLE} appropriately, and then only enables and defines bindings for the available types. OK to check in ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- A non-text attachment was scrubbed... Name: fftw.patch Type: text/x-patch Size: 5619 bytes Desc: not available URL: From don at codesourcery.com Fri May 30 08:44:10 2008 From: don at codesourcery.com (Don McCoy) Date: Fri, 30 May 2008 02:44:10 -0600 Subject: [patch] outer and dot products using CML Message-ID: <483FBE5A.9020301@codesourcery.com> This patch adds support for vector products outer and dot. Note that the 'alpha' parameter is not supported in the CML call directly, so this results in an extra iteration through the output matrix. Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cop.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cop.diff URL: From jules at codesourcery.com Fri May 30 20:10:52 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 30 May 2008 16:10:52 -0400 Subject: [vsipl++] patch: enable/disable fftwf, fftw, and fftwl individually In-Reply-To: <483F91C5.5060701@codesourcery.com> References: <483F91C5.5060701@codesourcery.com> Message-ID: <48405F4C.8040305@codesourcery.com> Stefan Seefeld wrote: > The attached patch probes at configure-time for those three libraries, > defines VSIP_IMPL_FFTW3_HAVE_{FLOAT, DOUBLE, LONG_DOUBLE} appropriately, > and then only enables and defines bindings for the available types. > > OK to check in ? Stefan, The provide_fft_{float,double,long_double} variables advertise to the program what FFT types are supported. They are global across all the different backends. provide_fft_{float,double,long_double} are initially set to 0. If a backend is enabled that provides a certain FFT (say SAL provides float FFT, or IPP provides double), then the appropriate variable is set to 1. This gets used to set the VSIP_IMPL_PROVIDE_FFT_{TYPE} macros in configure.ac. If the FFTW3 BE clears these flags back to 0 as part of its configuration logic, any 1's set by FFT BEs earlier in the list will be overwritten. An easy way to resolve this is to use a new set of variables specific to FFTW3. "fftw3_has_{type}" for example. -- Jules > Index: m4/fft.m4 > =================================================================== > --- m4/fft.m4 (revision 209798) > +++ m4/fft.m4 (working copy) > @@ -184,7 +184,6 @@ > LIBS=$keep_LIBS]) > fi > fi > - > if test "$enable_builtin_fft" != "no"; then > > AC_MSG_NOTICE([Using built-in FFTW3 support.]) > @@ -206,15 +205,19 @@ > AC_MSG_RESULT([not a supported type.]) > AC_MSG_NOTICE([Disabling FFT support (--disable-fft-long-double).]) > enable_fft_long_double=no > + provide_fft_long_double=0 This may hide a '1' set by another BE. > elif test $ac_cv_sizeof_long_double = $ac_cv_sizeof_double; then > AC_MSG_RESULT([same size as double.]) > AC_MSG_NOTICE([Disabling FFT support (--disable-fft-long-double).]) > enable_fft_long_double=no > + provide_fft_long_double=0 Likewise. > else > AC_MSG_RESULT([supported.]) > + provide_fft_long_double=1 > fi > + provide_fft_float=1 > + provide_fft_double=1 The idea is that provide_fft_{type} is initialized to 0, then set to 1 when BE support is discovered. Setting to 1 first, then clearing if FFTW3 doesn't support the type won't play nicely with other backends. > Index: src/vsip/opt/fftw3/fft.hpp These changes look good. > Index: src/vsip/opt/fftw3/fft.cpp Likewise. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Fri May 30 20:17:57 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 30 May 2008 16:17:57 -0400 Subject: [vsipl++] [patch] outer and dot products using CML In-Reply-To: <483FBE5A.9020301@codesourcery.com> References: <483FBE5A.9020301@codesourcery.com> Message-ID: <484060F5.2020808@codesourcery.com> Don McCoy wrote: > This patch adds support for vector products outer and dot. Note that > the 'alpha' parameter is not supported in the CML call directly, so this > results in an extra iteration through the output matrix. > > Ok to commit? Don, This looks good. I'll add an issue to extend CML outer to include alpha. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From stefan at codesourcery.com Fri May 30 20:57:22 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Fri, 30 May 2008 16:57:22 -0400 Subject: [vsipl++] patch: enable/disable fftwf, fftw, and fftwl individually In-Reply-To: <48405F4C.8040305@codesourcery.com> References: <483F91C5.5060701@codesourcery.com> <48405F4C.8040305@codesourcery.com> Message-ID: <48406A32.5030102@codesourcery.com> Jules, thanks for your feedback. Please find attached the relevant part of the patch, somewhat revised: * I moved the definition of 'provide_fft_' to configure.ac to make sure it gets initialized to 0 before any test will set it. * I fixed code (in configure.ac) that assumed its default value was '', not '0'. * I use fftw_has_ in my fftw tests, and then propagate any 'on' flags to 'provide_fft_'. OK ? Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From jules at codesourcery.com Fri May 30 21:40:08 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 30 May 2008 17:40:08 -0400 Subject: [vsipl++] patch: enable/disable fftwf, fftw, and fftwl individually In-Reply-To: <48406A32.5030102@codesourcery.com> References: <483F91C5.5060701@codesourcery.com> <48405F4C.8040305@codesourcery.com> <48406A32.5030102@codesourcery.com> Message-ID: <48407438.7040301@codesourcery.com> Stefan Seefeld wrote: > Jules, > > thanks for your feedback. Please find attached the relevant part of the > patch, somewhat revised: Overall this looks good, I just have a couple of questions. > > * I moved the definition of 'provide_fft_' to configure.ac to make > sure it gets initialized to 0 before any test will set it. Sounds good. Looks like an artifact of the configure.ac break-up. > > * I fixed code (in configure.ac) that assumed its default value was '', > not '0'. Why change this? Since provide_fft_{type} is always 0 or 1, the current behavior defines VSIP_IMPL_PROVIDE_FFT_{TYPE} to 0 or 1. The new behavior defines it to 1 or leaves it undefined. This will break existing logic relies on this (i.e. '#if VSIP_IMPL_PROVIDE_FFT_{TYPE} && XYZ'). > > * I use fftw_has_ in my fftw tests, and then propagate any 'on' > flags to 'provide_fft_'. Sound good. > +if test "$neutral_acconfig" = 'y'; then > + if test $fftw_has_float = 1; then > + CPPFLAGS="$CPPFLAGS -DVSIP_IMPL_FFTW3_HAVE_FLOAT" > + fi Is this portable? In particular, since fftw_has_float may not be defined, does this create a problem older broken 'sh's? (I would love to get rid of all that "x$foo" cruft in configure, so I hope we do it for a reason!) -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From stefan at codesourcery.com Sat May 31 14:36:14 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Sat, 31 May 2008 10:36:14 -0400 Subject: [vsipl++] patch: enable/disable fftwf, fftw, and fftwl individually In-Reply-To: <48407438.7040301@codesourcery.com> References: <483F91C5.5060701@codesourcery.com> <48405F4C.8040305@codesourcery.com> <48406A32.5030102@codesourcery.com> <48407438.7040301@codesourcery.com> Message-ID: <4841625E.7070505@codesourcery.com> Jules Bergmann wrote: >> * I fixed code (in configure.ac) that assumed its default value was >> '', not '0'. > > Why change this? The 'provide_...' macros have values of either '0' or '1', but never ''. Thus, the original test: > if test "x$provide_fft_long_double" != "x"; then will always succeed. I don't mind whether we use 0/1 or ''/'something', but we should either test the real state or not test at all. So, the least disruptive change would be just to take out the test, as it is always true. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718