You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(8) |
Jul
(16) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(4) |
Feb
(3) |
Mar
(5) |
Apr
|
May
(24) |
Jun
|
Jul
(5) |
Aug
(17) |
Sep
|
Oct
(6) |
Nov
(9) |
Dec
(8) |
2012 |
Jan
(5) |
Feb
(14) |
Mar
(25) |
Apr
(7) |
May
(15) |
Jun
(12) |
Jul
(22) |
Aug
(4) |
Sep
(10) |
Oct
(10) |
Nov
(19) |
Dec
(17) |
2013 |
Jan
(8) |
Feb
(10) |
Mar
(16) |
Apr
(3) |
May
(16) |
Jun
(26) |
Jul
|
Aug
(9) |
Sep
|
Oct
(8) |
Nov
(17) |
Dec
(2) |
2014 |
Jan
(37) |
Feb
(15) |
Mar
(6) |
Apr
(9) |
May
(11) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(19) |
Oct
(4) |
Nov
(22) |
Dec
(21) |
2015 |
Jan
|
Feb
(7) |
Mar
(2) |
Apr
(17) |
May
(22) |
Jun
(11) |
Jul
(11) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(5) |
Dec
|
2016 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(8) |
May
(8) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2017 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(19) |
May
|
Jun
(7) |
Jul
(7) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
(3) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(2) |
Dec
|
2019 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2020 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
(31) |
Dec
(4) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric C. <eri...@gm...> - 2011-03-19 00:12:02
|
The optional library examples (eg Eigen) won't build for macs, because of a small bug in CMakeLists in ViennaCL 1.1.1. Basically, the command "TARGET_LINK_LIBRARIES(xxx OpenCL)" will generate a link-time error for macs. A simple way to avoid this error is to encapsulate all such commands in an if-block: IF((${CMAKE_SYSTEM_NAME} MATCHES "Linux") OR (${CMAKE_SYSTEM_NAME} MATCHES "Windows")) TARGET_LINK_LIBRARIES(xxx OpenCL) ENDIF((${CMAKE_SYSTEM_NAME} MATCHES "Linux") OR (${CMAKE_SYSTEM_NAME} MATCHES "Windows")) What I'm suggesting is exactly what you did for the executables further up in the file. - Eric |
From: Eric C. <eri...@gm...> - 2011-03-18 22:51:14
|
Hi, First, thanks for all the foresight and hard work that went into envisioning and building ViennaCL. Second, I've got a bug report: I've got: Core i5 Macbook Pro with OS X 10.6.6, NVIDIA GeForce GT 330M (512MB), ViennaCL 1.1.1. When I compile the default CMake targets and run "./vectorparms", I get the following output: """ ---------------------------------------------- Device Info ---------------------------------------------- CL Device Vendor ID: 16918016 CL Device Name: GeForce GT 330M CL Driver Version: CLH 1.0 -------------------------------- CL Device Max Compute Units: 6 CL Device Max Work Group Size: 512 CL Device Global Mem Size: 536870912 CL Device Local Mem Size: 16384 ---------------------------------------------- ---------------------------------------------- ## Benchmark :: Vector ---------------------------------------------- ------------------------------- # benchmarking single-precision ------------------------------- ------- Related to vector addition ---------- Best parameter set for add: [1024 global workers, 256 local workers] 0.044644 Default parameter set: [16384 global workers, 128 local workers] 0.161912 Best parameter set for inplace_add: [16384 global workers, 128 local workers] 0.007211 Default parameter set: [16384 global workers, 128 local workers] 0.007211 ViennaCL: FATAL ERROR: Kernel start failed for 'mul_add'. ViennaCL: Smaller work sizes could not solve the problem. terminate called after throwing an instance of 'viennacl::ocl::invalid_command_queue' what(): ViennaCL: FATAL ERROR: CL_INVALID_COMMAND_QUEUE. If you think that this is a bug in ViennaCL, please report it at vie...@li... and supply at least the following information: * Operating System * Which OpenCL implementation (AMD, NVIDIA, etc.) * ViennaCL version Many thanks in advance! Abort trap """ Cheers, Eric |
From: Karl R. <ru...@iu...> - 2011-03-17 21:46:38
|
Dear ViennaCL users, version 1.1.1 is now available for download. The highlights of the new release are as follows: * New out-of-the-box support for Eigen (see http://eigen.tuxfamily.org/ ) and MTL 4 (see http://www.mtl4.org/ ) libraries. Iterative solvers from ViennaCL can now directly be used with both libraries. * Better default parameter for BLAS3 routines leads to higher performance for matrix-matrix-products. * Cleaned up CMakeLists.txt in order to selectively enable builds that rely on external libraries. * Removed the accidental external linkage for three functions in order to preserve the true header-only flavour of ViennaCL. We are open for any suggestions on further improvements and future developments. In particular, if you think that ViennaCL should provide built-in wrappers for Your Favorite Linear Algebra Library, just drop as a short note. Best regards, Karl Rupp |
From: Malte H. <mal...@go...> - 2011-02-06 16:13:31
|
Thanks, it seems that, this is indeed the problem. I did not spend any thoughts on memory limitations on the graphics card. I don't think I will need tiling, as there are a lot of optimizations that can be done to reduce the calculation to a sparse-matrix vector product which should be far from exceeding the memory, even on my development system. Best, Malte On Sun, 2011-02-06 at 11:06 +0100, Karl Rupp wrote: > Hi Malte! > > The CL_OUT_OF_RESOURCES is most likely due to the exhausted GPU-RAM. > Considering that you compute the matrix-matrix-product of two 3000 x > 3000 matrices and write the result to another 3000 x 3000 matrix, a > total of 3 x 3000 x 3000 = 24 Mio entries have to be stored. With 4 > bytes per entry in single precision, this results in about 96 MB of > memory. I suppose that your GeForce GM 320 provides only 128 or 256 MB > of memory, so there is simply no more memory left for larger matrices. > > One remedy for larger matrix-matrix products is to decompose the system > matrix into smaller tiles (e.g. decompose 3000 x 3000 matrices into four > 1500 x 1500 matrices) and to have only two tiles at the same time on the > GPU. > > Hence, there are two options at present: Either use a graphics board > with more memory, or implement the tiling outlined above by hand. > > Best regards, > Karli > > > > On 02/06/2011 02:40 AM, Malte Harder wrote: > > Hi there, > > > > I have a problem using ViennaCL in one of my projects. I did some small > > OpenCL tests before, but I never really used it because there was no > > quick& easy way to plug it into Eigen which I usually use for linear > > algebra computations. ViennaCL seems to solve this problem very > > conveniently! > > > > However, I keep getting CL_OUT_OF_RESOURCES errors in a simple matrix > > multiplication. Is this the normal behaviour when the matrix is larger > > (in my case 3000x3000) than the work item sizes? > > > > I'm on a 64bit Arch Linux with Nvidia drivers 260.19.21, a GeForce GM > > 320 and I'm using the kernel parameters generated by the kernelparam > > programs supplied with the latest version of the library. > > > > Best regards, > > Malte > > > > > > > > ------------------------------------------------------------------------------ > > The modern datacenter depends on network connectivity to access resources > > and provide services. The best practices for maximizing a physical server's > > connectivity to a physical network are well understood - see how these > > rules translate into the virtual world? > > http://p.sf.net/sfu/oracle-sfdevnlfb > > > > > > > > _______________________________________________ > > ViennaCL-support mailing list > > Vie...@li... > > https://lists.sourceforge.net/lists/listinfo/viennacl-support > |
From: Karl R. <ru...@iu...> - 2011-02-06 10:06:45
|
Hi Malte! The CL_OUT_OF_RESOURCES is most likely due to the exhausted GPU-RAM. Considering that you compute the matrix-matrix-product of two 3000 x 3000 matrices and write the result to another 3000 x 3000 matrix, a total of 3 x 3000 x 3000 = 24 Mio entries have to be stored. With 4 bytes per entry in single precision, this results in about 96 MB of memory. I suppose that your GeForce GM 320 provides only 128 or 256 MB of memory, so there is simply no more memory left for larger matrices. One remedy for larger matrix-matrix products is to decompose the system matrix into smaller tiles (e.g. decompose 3000 x 3000 matrices into four 1500 x 1500 matrices) and to have only two tiles at the same time on the GPU. Hence, there are two options at present: Either use a graphics board with more memory, or implement the tiling outlined above by hand. Best regards, Karli On 02/06/2011 02:40 AM, Malte Harder wrote: > Hi there, > > I have a problem using ViennaCL in one of my projects. I did some small > OpenCL tests before, but I never really used it because there was no > quick& easy way to plug it into Eigen which I usually use for linear > algebra computations. ViennaCL seems to solve this problem very > conveniently! > > However, I keep getting CL_OUT_OF_RESOURCES errors in a simple matrix > multiplication. Is this the normal behaviour when the matrix is larger > (in my case 3000x3000) than the work item sizes? > > I'm on a 64bit Arch Linux with Nvidia drivers 260.19.21, a GeForce GM > 320 and I'm using the kernel parameters generated by the kernelparam > programs supplied with the latest version of the library. > > Best regards, > Malte > > > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > > > > _______________________________________________ > ViennaCL-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support |
From: Malte H. <mal...@go...> - 2011-02-06 01:40:57
|
Hi there, I have a problem using ViennaCL in one of my projects. I did some small OpenCL tests before, but I never really used it because there was no quick & easy way to plug it into Eigen which I usually use for linear algebra computations. ViennaCL seems to solve this problem very conveniently! However, I keep getting CL_OUT_OF_RESOURCES errors in a simple matrix multiplication. Is this the normal behaviour when the matrix is larger (in my case 3000x3000) than the work item sizes? I'm on a 64bit Arch Linux with Nvidia drivers 260.19.21, a GeForce GM 320 and I'm using the kernel parameters generated by the kernelparam programs supplied with the latest version of the library. Best regards, Malte |
From: Karl R. <ru...@iu...> - 2011-01-10 10:11:40
|
Hi Evan, thanks for your email. The issue is only partly due to OpenCL 1.1. Recent NVIDIA drivers do not ship their own OpenCL header files any longer, so one has to manually get them from the Khronos group. If you are updating to recent NVIDIA drivers, the old header files might still be in place. It seems that the earlier NVIDIA header files are not 100 percent compatible, e.g. CL_INVALID_PROPERTY is not defined. Anyway, it should be sufficient if you just comment that particular line(s) in error.hpp. Best regards, Karli On 01/10/2011 10:31 AM, Evan Bollig wrote: > I just grabbed ViennaCL 1.1 and got this error on a machine with an > NVidia GPU. I think youre forgetting a check for OpenCL 1.1. My system > is only OpenCL 1.0. > > In static member function 'static void > viennacl::ocl::error_checker<T>::raise_exception(cl_int)': > viennacl/ocl/error.hpp:553: error: 'CL_INVALID_PROPERTY' was not > declared in this scope > > -Evan > |
From: Evan B. <bo...@gm...> - 2011-01-10 09:31:34
|
I just grabbed ViennaCL 1.1 and got this error on a machine with an NVidia GPU. I think youre forgetting a check for OpenCL 1.1. My system is only OpenCL 1.0. In static member function 'static void viennacl::ocl::error_checker<T>::raise_exception(cl_int)': viennacl/ocl/error.hpp:553: error: 'CL_INVALID_PROPERTY' was not declared in this scope -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Karl R. <ru...@iu...> - 2011-01-09 16:36:46
|
Hi Federico! Most operations are asynchronous, as long as no OpenCL data transfer is involved. This essentially involves creating objects, the copy() functions as well as some of the convenience casts for viennacl::scalar<> plus the resize operations to host scalars. However, adding up vectors, multiplying matrices and the like is asynchronous. One example: //creating ViennaCL objects is blocking: viennacl::vector<double> v1(100); viennacl::vector<double> v2(100); viennacl::matrix<double> mat1(100, 100); viennacl::matrix<double> mat2(100, 100); //copy is blocking: viennacl::copy(my_vector, v1); viennacl::copy(my_vector, v1); viennacl::copy(my_matrix, mat1); viennacl::copy(my_matrix, mat2); //Operations are non-blocking: v1 += v2; v2 -= v1; v1 = viennacl::linalg::prod(mat1, v2); mat1 += mat2; //here you can do some CPU computations while ViennaCL operations are carried out in the background //read operations are blocking again: viennacl::copy(v1, my_result_vector); viennacl::copy(mat1, my_result_matrix); Best regards, Karli On 01/09/2011 05:22 PM, Fedechicco wrote: > Hello, > I'm working on a math project with OpenCL and ViennaCL is exactly what > I'd like to use. > Unfortunately this project of mine requires computation to be done on > both CPU and GPU, for better speed, so I'd like to have asynchronous > data transfers, asynchronous kernel calls, etc. etc. > > Does ViennaCL have the possibility to execute those asynchronous > operations? I didn't find clues on the manual. > > Thank you very much, > Federico > |
From: Fedechicco <fed...@da...> - 2011-01-09 16:22:33
|
Hello, I'm working on a math project with OpenCL and ViennaCL is exactly what I'd like to use. Unfortunately this project of mine requires computation to be done on both CPU and GPU, for better speed, so I'd like to have asynchronous data transfers, asynchronous kernel calls, etc. etc. Does ViennaCL have the possibility to execute those asynchronous operations? I didn't find clues on the manual. Thank you very much, Federico -- Calendario con i miei impegni: http://www.google.com/calendar/embed?src=fedechicco%40gmail.com&ctz=Europe/Paris DarkBios Community site: http://www.darkbios.it |
From: Karl R. <ru...@iu...> - 2010-12-29 18:46:03
|
Hi Gordon, I think it should be sufficient to declare the three functions readTextFromFile() strReplace() make_double_kernel() in viennacl/tools/tools.hpp, lines 87, 107 and 143 to be inline. If this is not sufficient, you can make these functions template functions in order to eliminate the external linkage. Thanks for reporting the issue, we will fix this in the next revision of ViennaCL. Hope that helps. :-) Best regards, Karli On 12/29/2010 03:38 AM, Gordon Stevenson wrote: > I'm building viennacl with an ITK build using visual studio. For > stupid reasons, i'm not using cmake to build and am managing it with > the property settings in visual studio 2008. I'm picking up a weird > error in linking. > > > 1>pview.obj : error LNK2005: "class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > __cdecl > viennacl::tools::readTextFromFile(class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > const&)" > (?readTextFromFile@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@@Z) > already defined in main.obj > 1>pview.obj : error LNK2005: "class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > __cdecl > viennacl::tools::strReplace(class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > const&,class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> >,class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> >)" > (?strReplace@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@V34@1@Z) > already defined in main.obj > 1>pview.obj : error LNK2005: "class std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > __cdecl > viennacl::tools::make_double_kernel(class > std::basic_string<char,struct std::char_traits<char>,class > std::allocator<char> > const&)" > (?make_double_kernel@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@@Z) > already defined in main.obj > >> From my understanding of this error, it is to do with headers being > multiply defined. Is there any ideas from the list how to solve? > > Cheers, > > G. > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > ViennaCL-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support > |
From: Gordon S. <gor...@lm...> - 2010-12-29 02:39:04
|
I'm building viennacl with an ITK build using visual studio. For stupid reasons, i'm not using cmake to build and am managing it with the property settings in visual studio 2008. I'm picking up a weird error in linking. 1>pview.obj : error LNK2005: "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl viennacl::tools::readTextFromFile(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?readTextFromFile@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@@Z) already defined in main.obj 1>pview.obj : error LNK2005: "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl viennacl::tools::strReplace(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)" (?strReplace@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@V34@1@Z) already defined in main.obj 1>pview.obj : error LNK2005: "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl viennacl::tools::make_double_kernel(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?make_double_kernel@tools@viennacl@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEBV34@@Z) already defined in main.obj >From my understanding of this error, it is to do with headers being multiply defined. Is there any ideas from the list how to solve? Cheers, G. |
From: Karl R. <ru...@iu...> - 2010-12-26 10:06:52
|
Hi Vlad, thanks for reporting the issue with CL_INVALID_PROPERTY, I suppose this is due to the OpenCL 1.0 implementation in MacOS. The error during the openclbench is due to a rather large matrix, which you can change easily: In examples/benchmarks/openclbench.hpp, change the line 65 viennacl::matrix<ScalarType> vcl_matrix(BENCHMARK_VECTOR_SIZE/10, BENCHMARK_VECTOR_SIZE/10); to viennacl::matrix<ScalarType> vcl_matrix(BENCHMARK_VECTOR_SIZE/100, BENCHMARK_VECTOR_SIZE/100); The openclbench should run smoothly then. Without changing this line, the allocation of the 10.000 by 10.000 dense matrix fails due to the rather small memory on your GPU, that's why the error is thrown. Btw: It's interesting to see that the kernel compilation times on your machine are much shorter than on my standard machine (up to a factor of five). Best regards, Karli On 12/26/2010 10:38 AM, Vlad-Andrei Lazar wrote: > Hey, > > I have to say i've been waiting for a while for such a package to appear. > However I ran into some slight troubles: > > 1) CL_INVALID_PROPERTY is not defined in any of my headers so I had to comment out error.hpp:533 > 2)When I run openclbench i am getting: > > ---------------------------------------------- > Device Info > ---------------------------------------------- > CL Device Vendor ID: 16918016 > CL Device Name: GeForce 9400M > CL Driver Version: CLH 1.0 > -------------------------------- > CL Device Max Compute Units: 2 > CL Device Max Work Group Size: 512 > CL Device Global Mem Size: 268435456 > CL Device Local Mem Size: 16384 > > > ---------------------------------------------- > ---------------------------------------------- > ## Benchmark :: OpenCL performance > ---------------------------------------------- > > ------------------------------- > # benchmarking single-precision > ------------------------------- > Time for building scalar kernels: 0.05125 > Time for building vector kernels: 0.124655 > terminate called after throwing an instance of 'viennacl::ocl::invalid_buffer_size' > what(): ViennaCL: FATAL ERROR: CL_INVALID_BUFFER_SIZE. > > I am running all this under MacOS 10.6.5, using the Apple openCL implementation. > > Hope this helps to iron out the kinks. > > Best regards, > Vlad > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > ViennaCL-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support > |
From: Vlad-Andrei L. <cl...@gm...> - 2010-12-26 09:38:23
|
Hey, I have to say i've been waiting for a while for such a package to appear. However I ran into some slight troubles: 1) CL_INVALID_PROPERTY is not defined in any of my headers so I had to comment out error.hpp:533 2)When I run openclbench i am getting: ---------------------------------------------- Device Info ---------------------------------------------- CL Device Vendor ID: 16918016 CL Device Name: GeForce 9400M CL Driver Version: CLH 1.0 -------------------------------- CL Device Max Compute Units: 2 CL Device Max Work Group Size: 512 CL Device Global Mem Size: 268435456 CL Device Local Mem Size: 16384 ---------------------------------------------- ---------------------------------------------- ## Benchmark :: OpenCL performance ---------------------------------------------- ------------------------------- # benchmarking single-precision ------------------------------- Time for building scalar kernels: 0.05125 Time for building vector kernels: 0.124655 terminate called after throwing an instance of 'viennacl::ocl::invalid_buffer_size' what(): ViennaCL: FATAL ERROR: CL_INVALID_BUFFER_SIZE. I am running all this under MacOS 10.6.5, using the Apple openCL implementation. Hope this helps to iron out the kinks. Best regards, Vlad |
From: Karl R. <ru...@iu...> - 2010-12-25 22:15:17
|
Dear subscribers, just a quick copy&paste from the news-section: Even though not initially intended, the new version 1.1.0 is now just in time for Christmas! The highlights of the new release are as follows: - Full BLAS level 3 support - Multi-GPU support - Two additional preconditioners - Automated performance tuning environment - ViennaCL can operate with existing, user-provided OpenCL contexts - Better support for STL emulated vector and matrix types - ViennaCL now has a logo :-) - Error handling now using exceptions - Improved performance of vector norm kernels. Thanks for the patience and merry christmas to all users of ViennaCL! Best regards, Karli |
From: Karl R. <ru...@iu...> - 2010-08-27 08:59:26
|
Hi Samir, I suggest that you write a small C++ function containing that part of code you want to optimize (e.g. a sparse matrix-vector multiplication with ViennaCL), and declare the function as "extern C" so that you can call the function from within your Fortran code. I guess that is the simplest solution for your case. There are at present no plans to provide a full-fledged interface to Fortran with ViennaCL, because simple Fortran function interfaces are already provided by many other GPU libraries. The ViennaCL types use too much of syntatic sugar such as expression templates which cannot be mapped to Fortran functions easily. I hope that helps :-) Best regards, Karli On 08/26/2010 06:20 PM, Samir Unni wrote: > Hi, > > I'm interested in using ViennaCL to optimize some code, but it's written > in Fortran. Would it be possible to create some kind of interface so > that ViennaCL variable types and functions would be accessible from > Fortran, or is that impossible? > > Thanks, > > Samir Unni > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > > > _______________________________________________ > ViennaCL-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support |
From: Samir U. <sr...@cc...> - 2010-08-26 16:21:20
|
Hi, I'm interested in using ViennaCL to optimize some code, but it's written in Fortran. Would it be possible to create some kind of interface so that ViennaCL variable types and functions would be accessible from Fortran, or is that impossible? Thanks, Samir Unni |
From: Karl R. <ru...@iu...> - 2010-08-12 15:43:40
|
Hi Jason, you are right, the handle can now directly be obtained from the iterators, but unfortunately we have missed to update the fast_copy() function. Thanks for reporting this issue :-) As a quick fix, replacing "gpu_begin.get_vector_readable().handle()" with "gpu_begin.handle()" around line 1235 and 1302 and "const vector_iterator<SCALARTYPE, ALIGNMENT> & gpu_begin)" with "vector_iterator<SCALARTYPE, ALIGNMENT> gpu_begin)" around line 1295 should be sufficient. This will be corrected in the next version 1.1.0. Regarding ublas objects with iterative solvers, please refer to the tutorial "tut4.cpp", where this is demonstrated. In short: Just pass ublas::compressed_matrix<> and ublas::vector<> instead of the ViennaCL types to the solver calls ;-) Best regards, Karli On 08/12/2010 03:32 PM, Jason M wrote: > Hello, > > In fast_copy in vector.hpp, I am getting compile errors for gpu to > cpu (line 1232) and cpu to gpu (line 1297). It seems that the > functions > > const_vector_iterator::get_vector_readable() > const_vector_iterator::get_vector() > vector_iterator::get_vector_writeable() > > were deleted in 1.0.5 and fast_copy was not updated for this. > > > I also have a question regarding the manual. For direct solvers it > mentions, "The iterative solvers can directly be used for ublas > objects!". How can ublas objects be used with the iterative solvers? > > > > -Jason > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > ViennaCL-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support > |
From: Jason M <ja...@gm...> - 2010-08-12 13:32:10
|
Hello, In fast_copy in vector.hpp, I am getting compile errors for gpu to cpu (line 1232) and cpu to gpu (line 1297). It seems that the functions const_vector_iterator::get_vector_readable() const_vector_iterator::get_vector() vector_iterator::get_vector_writeable() were deleted in 1.0.5 and fast_copy was not updated for this. I also have a question regarding the manual. For direct solvers it mentions, "The iterative solvers can directly be used for ublas objects!". How can ublas objects be used with the iterative solvers? -Jason |
From: Karl R. <ru...@iu...> - 2010-08-04 13:58:15
|
Hi Evan, yes, it is possible, and it uses the same OpenCL kernels as the GPU version. If there is no suitable GPU available, it automatically probes for a supported CPU and uses that if possible (e.g. with Stream SDK). If you have a machine that has both a good GPU and a supported CPU and you still want to run it on the CPU, then one line of code in the ViennaCL implementation needs to be adjusted. We plan to provide here a more customizable interface soon. Best regards, Karli On 08/04/2010 12:10 AM, Evan Bollig wrote: > Hey guys, > > Is it possible to use ViennaCL in CPU only mode (i.e. not run on the > GPU?). If I do this, does it still run the OpenCL kernels but in CPU > mode, or are there algorithms implemented that do not use OpenCL? > > -Evan > |
From: Evan B. <bo...@sc...> - 2010-08-03 22:10:39
|
Hey guys, Is it possible to use ViennaCL in CPU only mode (i.e. not run on the GPU?). If I do this, does it still run the OpenCL kernels but in CPU mode, or are there algorithms implemented that do not use OpenCL? -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Karl R. <ru...@iu...> - 2010-07-29 18:00:57
|
Hey Evan, the idea of providing a MatrixMarket reader is really good, I think this can make it into the next release 1.0.5 :-) Other sparse matrix formats are under consideration, especially a hybrid format is in preparation in order to speed up typical applications. Contributions are always welcome, especially since time is flying by so quickly and other issues like effective preconditioners and BLAS level 3 support also need to be tackled... :-) Best regards, Karli On 07/29/2010 06:45 PM, Evan Bollig wrote: > Hey guys Im working with ViennaCL for sparse matrix support. I also > considered CUSP (cusp-library.googlecode.com) and CNC (part of > OpenNL). One feature I really appreciate in CUSP is the ability to > read in MatrixMarket files. Have you considered adding this to > ViennaCL? What about adding additional sparse matrix formats like DIA, > ELL, HYB and BCSR? > > I am close to a working product with the formats you offer in release > 1.0.4, so I might add this stuff myself and see if I can improve > performance. That is, assuming you havent already added them in the > nightly build. > > -Evan > |
From: Evan B. <bo...@sc...> - 2010-07-29 16:46:14
|
Hey guys Im working with ViennaCL for sparse matrix support. I also considered CUSP (cusp-library.googlecode.com) and CNC (part of OpenNL). One feature I really appreciate in CUSP is the ability to read in MatrixMarket files. Have you considered adding this to ViennaCL? What about adding additional sparse matrix formats like DIA, ELL, HYB and BCSR? I am close to a working product with the formats you offer in release 1.0.4, so I might add this stuff myself and see if I can improve performance. That is, assuming you havent already added them in the nightly build. -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Evan B. <bo...@sc...> - 2010-07-28 21:36:30
|
Hey guys, FYI: I ran tut1 on OSX Snow leopard (actually this happens with all of the binaries built by ViennaCL). I have an 8600M GT (17" mbp). The program executes beautifully, but segfaults on exit when the destructors are called to cleanup OpenCL details. I tested it on a Linux machine with a GTX280 and no segfault. -Evan -- -Evan Bollig bo...@gm... bo...@sc... |
From: Karl R. <ru...@iu...> - 2010-07-20 07:38:14
|
Hi Jason, sorry, I just discovered that this issue still seems to be open. It can be solved by setting the work sizes to a smaller value. For that, change in viennacl/ocl/device.hpp the lines (154,155) _work_items_per_group = 128; _work_groups = 128; to _work_items_per_group = 64; _work_groups = 64; Then all tutorials and examples should run fine. :-) Best regards, Karli On 07/08/2010 09:58 PM, Lam, Jason wrote: > Tutorial 4 & 5 run without error > > System info: > > OS: Mac OS X Snow Leopard > > ATI Radeon HD 4870 > > ViennaCL 1.0.4 > > Snow Leopard as an implementation of OpenCL. I also installed CUDA SDK. > > ./tut1 > > CPU scalar s2: 1 > > GPU scalar vcl_s2: 1 > > Could not start kernel 'inner_prod' with global work size 1024 and local > work size 128. > > Error -54 in function start1D ( > /Users/ssoa/Downloads/ViennaCL-1.0.4/./viennacl/ocl/kernel.hpp:120 ) > CL_INVALID_WORK_GROUP_SIZE > > The supplied work group size is invalid. If you set this value manually, > please reconsider your choice. > > ./tut2 > > ----- Matrix-Vector product ----- > > ----- Transposed Matrix-Vector product ----- > > ----- Upper Triangular solve ----- > > Could not start kernel 'upper_triangular_substitute_inplace' with global > work size 128 and local work size 128. > > Error -54 in function start1D ( > /Users/ssoa/Downloads/ViennaCL-1.0.4/./viennacl/ocl/kernel.hpp:120 ) > CL_INVALID_WORK_GROUP_SIZE > > The supplied work group size is invalid. If you set this value manually, > please reconsider your choice. > > ./tut3 > > Reading ublas matrix > > done reading matrix > > done reading rhs > > done reading result > > ----- CG Test ----- > > Could not start kernel 'inner_prod' with global work size 1024 and local > work size 128. > > Error -54 in function start1D ( > /Users/ssoa/Downloads/ViennaCL-1.0.4/./viennacl/ocl/kernel.hpp:120 ) > CL_INVALID_WORK_GROUP_SIZE > > The supplied work group size is invalid. If you set this value manually, > please reconsider your choice. > > Thanks > > *Jason Lam > */703-367-6112/ > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > _______________________________________________ > Viennacl-support mailing list > Vie...@li... > https://lists.sourceforge.net/lists/listinfo/viennacl-support |