To give it some more underpinning, I searched for a benchmark. I only found one for cuda so far from 2012: http://www.timzaman.com/?p=2256 Results in a table: https://docs.google.com/spreadsheet/pub?key=0AkfBSyx6TpqMdDFnclY5UjlyNmVsSnhGV0hscnJQcVE&output=html Resulting graph:
I think the scale is speedup from using the gpu, so the cpu is always one. 2014-12-08 19:07 GMT+01:00 Simon Danisch <sdani...@gmail.com>: > Strictly faster is probably a little bit exaggerated > <http://www.dict.cc/englisch-deutsch/exaggerated.html>, but simple image > manipulations fit the GPU very well. This should be valid for all > algorithms which can be massively parallelized > <http://www.dict.cc/englisch-deutsch/parallelized.html> and don't use > scatter writes or reads. > So if you have decent video card, the cpu should have a hard time to match > the performance. > I'm not sure about the transfers, as OpenCV might actually do transfers > even in the UMat case... It's not that obvious how they manage their memory. > > 2014-12-08 18:58 GMT+01:00 Tim Holy <tim.h...@gmail.com>: > >> Now that you posted the code (along with timing markers), it's much >> clearer. >> Your timings are just for the computation, and don't include transfer >> time. >> >> My "misleading" statement was not intended as an accusation :-), merely >> trying >> to help explain the gaussian blur result: if you included transfer time >> in one >> but not the other, that might explain it. But from your posted code, it's >> clear that wasn't the problem. >> >> --Tim >> >> On Monday, December 08, 2014 09:54:03 AM Max Suster wrote: >> > Its an exact comparison side-by-side of the same code, and actually >> already >> > tested by others in the OpenCV forum. >> > The Mat/UMat image is available for display with imshow -- the step >> "imshow( >> > "edges", gray);" in both cases -- which is how the test was set up. The >> > main point is the time it takes to complete the entire process and the >> fact >> > that cvtColor with OpenCL can generate an image for viewing much more >> > quickly. >> > >> > I never intended to be misleading, and I am sorry that you interpret it >> > this way. >> > >> > Max >> > >> > On Monday, December 8, 2014 6:22:39 PM UTC+1, Tim Holy wrote: >> > > I wonder if the bigger problem might be that your numbers for the >> > > grayscale >> > > conversion (which were very promising) might be misleading. Are you >> sure >> > > the >> > > calculation is "done" (and the results are available to the CPU) by >> the >> > > time >> > > it finishes? If we assume a best-case scenario of 6GB/s of data >> transfer >> > > to the >> > > GPU, then transferring 3MB to the GPU and 1MB back takes about 0.7ms. >> > > That's >> > > many times longer than what you reported for that calculation. Or did >> you >> > > not >> > > include transfer time in your results? >> > > >> > > --Tim >> > > >> > > On Monday, December 08, 2014 05:50:32 PM Simon Danisch wrote: >> > > > That's interesting, gaussian blur should definitely be faster on the >> > > >> > > gpu! >> > > >> > > > Maybe this thread helps? >> > > > http://answers.opencv.org/question/34127/opencl-in-opencv-300/ >> > > > It seems like things are a little complicated, as it isn't really >> clear >> > > >> > > if >> > > >> > > > the data is currently in VRAM or RAM... >> > > > >> > > > 2014-12-08 17:39 GMT+01:00 Max Suster <mxss...@gmail.com >> <javascript:>>: >> > > > > Thanks for the feedback. I realize that the copying needs to be >> > > >> > > skipped >> > > >> > > > > if possible . . . >> > > > > I have been playing a bit with the OpenCL UMat and it will need >> indeed >> > > > > some tweeking because UMat is not always advantageous. >> > > > > While there 10x gain with cvtColor and other functions such as >> > > > > GasussianBlur are actually a little slower. >> > > > > >> > > > > I will have closer look at this tonight. >> > > > > >> > > > > Max >> > > > > >> > > > > On Monday, December 8, 2014 4:15:28 PM UTC+1, Simon Danisch wrote: >> > > > >> If you're interested here are some more links: >> > > > >> https://software.intel.com/en-us/articles/opencl-and-opengl-> >> >> > > >> > > interoperability-tutorial >> > > >> > > > >> Valentine's and mine prototype for OpenGL OpenCL >> interoperability in >> > > > >> Julia: >> > > > >> https://github.com/vchuravy/qjulia_gpu >> > > > >> >> > > > >> Am Samstag, 6. Dezember 2014 11:44:45 UTC+1 schrieb Max Suster: >> > > > >>> Hi all, >> > > > >>> >> > > > >>> A few months ago I set out to learn Julia in an attempt to find >> an >> > > > >>> alternative to MATLAB for developing computer vision >> applications. >> > > > >>> Given the interest (1 >> > > > >>> < >> > > >> > > >> https://groups.google.com/forum/#!searchin/julia-users/OpenCV/julia-use >> > > >> > > > >>> rs/PjyfzxPt8Gk/SuwKtjTd9j4J> ,2 >> > > > >>> < >> > > >> > > >> https://groups.google.com/forum/#!searchin/julia-users/OpenCV/julia-use >> > > >> > > > >>> rs/81V5zSNJY3Q/DRUT0dR2qhQJ> ,3 >> > > > >>> < >> > > >> > > >> https://groups.google.com/forum/%23!searchin/julia-users/OpenCV/julia-u >> > > >> > > > >>> sers/iUPqo8drYek/pUeHECk91AQJ> ,4 >> > > > >>> < >> > > >> > > >> https://groups.google.com/forum/%23!searchin/julia-users/OpenCV/julia-u >> > > >> > > > >>> sers/6QunG66MfNs/C63pDfI-EMAJ> ) and wide application of OpenCV >> for >> > > >> > > fast >> > > >> > > > >>> real-time computer vision applications, I set myself to put >> together >> > > >> > > a >> > > >> > > > >>> simple interface for OpenCV in Julia. Coding in Julia and >> > > >> > > developing >> > > >> > > > >>> the interface between C++ and Julia has been a lot of fun! >> > > > >>> >> > > > >>> OpenCV.jl aims to provide an interface for OpenCV < >> > > >> > > http://opencv.org/> >> > > >> > > > >>> computer vision applications (C++) directly in Julia >> > > > >>> <http://julia.readthedocs.org/en/latest/manual/>. It relies >> > > >> > > primarily >> > > >> > > > >>> on Keno´s amazing Cxx.jl <https://github.com/Keno/Cxx.jl>, the >> > > >> > > Julia >> > > >> > > > >>> C++ foreign function interface (FFI). You can find all the >> > > >> > > information >> > > >> > > > >>> on >> > > > >>> my package at https://github.com/maxruby/OpenCV.jl. >> > > > >>> >> > > > >>> You can download and run the package as follows: >> > > > >>> >> > > > >>> Pkg.clone("git://github.com/maxruby/OpenCV.jl.git")using OpenCV >> > > > >>> >> > > > >>> >> > > > >>> For MacOSX, OpenCV.jl comes with pre-compiled shared libraries, >> so >> > > >> > > it is >> > > >> > > > >>> extremely easy to run. For Windows and Linux, you will need to >> > > >> > > first >> > > >> > > > >>> compile the OpenCV libraries, but this is well documented and >> links >> > > >> > > to >> > > >> > > > >>> the >> > > > >>> instructions for doing so are included in the README.md file. >> > > > >>> >> > > > >>> The package currently supports most of OpenCV´s C++ API; >> however, at >> > > > >>> this point I have created custom wrappings for core, imgproc, >> > > >> > > videoio >> > > >> > > > >>> and highgui modules so that these are easy to use for anyone. >> > > > >>> >> > > > >>> The package also demonstrates/contains >> > > > >>> >> > > > >>> - preliminary interface with the Qt GUI framework (see >> imread() >> > > >> > > and >> > > >> > > > >>> imwrite() functions) >> > > > >>> - thin-wrappers for C++ objects such as std::vectors, >> > > >> > > std::strings >> > > >> > > > >>> - conversion from Julia arrays to C++ std::vector >> > > > >>> - conversion of Julia images (Images.jl) to Mat (OpenCV) - >> though >> > > > >>> this has much room for improvement (i.e., color handling) >> > > > >>> >> > > > >>> Please let me know if there are any features you would like to >> see >> > > >> > > added >> > > >> > > > >>> and I will try my best to integrate them. In the meantime, I >> will >> > > > >>> continue >> > > > >>> to integrate more advanced algorithms for computer vision and >> > > >> > > eventually >> > > >> > > > >>> extend the documentation as needed. >> > > > >>> >> > > > >>> Cheers, >> > > > >>> Max >> >> >
