JG's profile - activity

I'm surprised no one else has commented or addressed this. No one else out there cares that resizing causes significant differences - from a data perspective - between CPU and GPU?

Hi,

When comaparing the output of the CPU version of resize to the GPU version of resize, I noticed that the resize function on GPU is not interpolating correctly. In fact, it appears to be a simple pixel decimation instead of ANY type of interpolation. According to the docs, there are 3 supported interpolation methods, in my testing all of them produced the same result. I've tried the CV_INTER_LINEAR definition as well as the cv::INTER_LINEAR, both resulting in same output. The CPU resize output is correct.

Is there a configuration setting that enables this support during compile time? Or some other function/option/switch/method that needs to be set or invoked prior to a gpu resize call?

Thanks for any help!

Edit: Found a difference in my comparison, corrected it, and the CPU vs GPU resize is still different but it's closer... What differences should be expected if any? Should they be exactly identical?

Hi,

I've got several custom sections of CUDA kernel code that I need to debug. The application also contains OpenCV GPU code (but I'm not trying to debug any of that). If I comment all the OpenCV function calls, I can set a breakpoint in the NSight debugger and my breakpoint is hit just fine. If I put the OpenCV calls back in, my breakpoint is never hit. I believe the reason (although I'm not sure) is that all the OpenCV GPU kernel modules (of which there are about 40ish) are being loaded into the debugger and possibly causing a timeout or something in NSight... However, I'm not calling the majority of those kernels in my code, but I think they get loaded as part of starting up the OpenCV GPU subsystem. I've tried running against the release build of the OpenCV libraries as well with same issue.

So, my questions are:

(1) Has anyone else experienced this? (2) Can I either speedup or remove all the unused OpenCV CUDA kernel loads? (3) Are there configuration settings in NSight that anyone is aware of to make this work even with all the kernels being loaded?

I'm not that concerned with debugging speed or performance, but I'd like my breakpoint to be able to be hit while debugging my non-OpenCV code.

Thanks for any help! My System: Windows 7 64bit, Visual Studio 2010SP1, NSight 3.1, CUDA 5.5.12, OpenCV 2.4.6.0 built with CUDA support

Edit: Additionally, I've found that if I remove the OpenCV CUDA built binaries (the ones I built with CUDA support) from my path and use the pre-built non-GPU binaries instead, then my breakpoint is hit. This makes me think even more that the GPU binaries are loading/doing something that is preventing my custom CUDA code breakpoint from being hit.

Edit: Further testing and an OpenCV rebuild with CUDA support but without DEBUG information yielded the same results. If I exchange the opencv_gpu246*.dll with the prebuilt binary, I don't see this issue and I'm able to debug my custom kernels, but obviously I can't use any opencv gpu functions in my application as well... which are used in the pipeline prior to my custom kernel.

Edit: I'm not the only one experiencing these issues, and it seems to be the same one as this unanswered question as well.

Well, that's unfortunate. It was nice to have the proper GPU DLLs built and ready to use right out of the box. What was the reason for removal of the binaries? It seems that they would already be available if the other binaries are being built and verified against, why not just include them?

Hi, just upgraded from 2.4.3 to 2.4.6 on a Windows 7 machine. My builds are failing due to the gpu binaries missing from the build directory. Under 2.4.3 they were located under opencv/build/gpu. Were they relocated somewhere? Looking forward to trying out with CUDA 5.5. Thanks!

Getting this runtime error: OpenCV Error: No GPU support (The library is compiled without CUDA support) in unknown function, file ......\src\opencv\modules\core\src\gpumat.cpp, line 879