Certainly it's possible that the quality of the kernels varies. The blur case is presumably harder to write a good kernel for and more subject to the chosen schedule, because it has to access memory non-locally. The grayscale conversion is pointwise and so is fairly trivial. But I would have expected the blur kernel to be highly optimized; I agree it's a puzzling result.
But that table that Simon linked suggests it should be faster, so I wonder if there's something fishy going on. --Tim On Monday, December 08, 2014 10:04:32 AM Max Suster wrote: > Thanks Tim (I did not mean to be defensive). > I totally agree that it is best to get to the bottom of the issue so that > we can get it work! > > The point I was trying to make more generally is that there does seem to be > quite a bit of variability in the gains from > OpenCL-acceleration at least with OpenCV. It would be nice to figure out > how and which bits can truly be accelerated most efficiently > and which may not be worth spending a lot more energy on. . . > > Max > > On Monday, December 8, 2014 6:58:42 PM UTC+1, Tim Holy wrote: > > 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
