I have a program that uses opencv and oclMat.
When I tried to run this my PC gets slow and sometimes get freezed.
I guess there are two much memory in GPU. So, my question is how can I release the memory allocated by opencv ocl mat. I execute 4 kernels. Something like this:
I create the oclmat and call the kernel and pass the matrices to the kernel.The result is a ocl mat which is used in the following kernel. M3,M4,M8,M9,M5,M10 are matrices that hold data inside the kernel. I am not using local memory(as the target device does not support local memory). SO, I am using the above mentioned ocl mat as data holder. All the temporary calculated data inside the kernel is stored in those matrix. They work the way a local memory would have worked here.I do not need them in the next kernel. SO I want to free them. What is the process to do that?
oclmat M1,M2,M3,M4
kernel1 (M1,M2,M3,M4)
oclmat M5,M6
kernel2(M4,M5,M6)
oclmat M7,M8,M9
kernel3(M6,M7,M8,M9)
oclmat M10,M11
kernel2(M9,M10,M11)
Related
I am trying to understand this statement from GPU.js. I am trying to figure out how many GPU cores gpu.js can utilize in parallel? GPU these days can easily come with 1000+ cores. From the statement below, are we looking at 3 only cores? Thanks.
GPU.js does this beautifully using this.thread.x for 1D array data, this.thread.x and this.thread.y for 2D array data and this.thread.x, this.thread.y and this.thread.z for 3D array data. Each instance of the kernel code residing in an independent GPU core is assigned different values for these variables. Hence, each kernel code instance on each core can operate on different parts of the given array at the same time.
I have enabled the GPU option in accelerator tab but when I try to train my model GPU is not processing my data instead only CPU is processing.
You need to specifically use the packages like https://rapids.ai/ to move data from CPU to GPU. I am assuming you using something like pandas to do data operations.
Seems like a problem in your training code where you might not be properly sending model and input to device and thus ending up only using your CPU. Check out these Kaggle examples on how to use:
TPUs: https://www.kaggle.com/docs/tpu#tpu9
GPUs: https://www.kaggle.com/rj1993/kernel-with-gpu-example
Is there a way to directly copy previously allocated CUDA device data into an OpenCV GPU Mat? I would like to copy my data, previously initialized and filled by CUDA, into the OpenCV GPU mat. I would like to do so because I want solve a linear system of equations Ax = B by computing the inverse of the matrix A using OpenCV.
What I want to do is something like this:
float *dPtr;
gpuErrchk( cudaMalloc( (void**) &dPtr, sizeof(float) * height * width));
gpuErrchk( cudaMemset(dPtr, 0, sizeof(float) * height * width));
// modify dPtr in some way on the GPU
modify_dPtr();
// copy previously allocated and modified dPtr into OpenCV GPU mat?
// process GPU mat later - e.x. do a matrix inversion operation.
// extract raw pointer from GPU mat
EDIT:
The OpenCV documentation provides a GPU upload function.
Can the device pointer just be passed into that function as a parameter? If not, is there no other way to do such a data transfer? I don't want to copy data back and forth between the host and device memory, do my computation on a normal OpenCV Mat container, and copy back the results; my application is real-time. I am assuming that since there is no .at() function for a GPU Mat, as in the normal OpenCV Mat, there is no way to access the element at a particular location in the matrix? Also, does an explicit matrix inversion operation exist for the GPU Mat? The documentation does not provide a GPU Mat inv() function.
Just as talonmies posted in the comments, there is a constructor in the header of the GPU mat structure that allows the creation of a GPUMat header pointing to my previously allocated CUDA device data. This is what I had used:
cv::gpu::GpuMat dst(height, width, CV_32F, d_Ptr);
There is no need to figure out the step size because the constructor automatically evaluates it, given the width and height of the image.
Hopefully, when the support for OpenCV GPU functions becomes better, this post may be useful to someone.
EDIT
Another (probably) useful way is to utilize unified memory in CUDA. Pass the data into an OpenCV GPU and CPU mat, and continue operations from there.
I am trying to implement computer vision algorithm on my NVidia GPU with openCV. I am using openCV 2.4 and I am currently writing very simple programs to get accustomed to openCV. I wrote a simple code of transposing a matrix and also to implementing canny edge detection on GPU. The program is running perfectly but I need to deallocate the memory in both the CPU and GPU. So I am posting my code below :
int main(int argc,char *argv[])
{
int k;
cv::Mat src;
cv::Mat dest;
cv::Mat dest_1;
cv::gpu::GpuMat im_source;
cv::gpu::GpuMat im_dest;
cv::gpu::GpuMat im_dest_1;
cv::gpu::Stream::Null;
k = cv::gpu :: getCudaEnabledDeviceCount();
printf("%d\n",k);
src = cv::imread("lena.jpg",0);
cv::imshow("lena_org",src);
im_source.upload(src);
cv::gpu::transpose(im_source,im_dest);
im_dest.download(dest);
cv::imshow("lena_trans",dest);
cv::gpu::Canny(im_source,im_dest_1,100,100,3,false);
im_dest_1.download(dest_1);
cv::imshow("lena_edge",dest_1);
cv::waitKey();
}
So from the code above I believe the memory is not getting freed in both the CPU and GPU. I was searching the internet a bit and I came across with cv::Mat::Release for cpu and cv::gpu::GpuMat::Release for the GPU side. But I am not getting how to use them or how I should use this functions in my code so that I could free bot my CPU and GPU memories. It would be very much helpful if someone could guide me through correct usage of the Release apis so that I could free the memory successfully. Thanks for all your support.
The destructor for cv::Mat objects automatically frees the memory, making calls to the release function you describe. At the level of your code, you shouldn't have to worry about that. Once the matrix leaves scope, it gets destroyed.
If you want to manually destroy your reference to the data, you can call, for example, src.release(). There is a good tutorial on memory management in the OpenCV documentation, available here
I noticed that a new data structure cv::Matx was added to the new OpenCV version, intended for small matrices of known size at compilation time, for example
cv::Matx31f // matrix 3x1 of float type
Checking the documentation I saw that most of matrix operations are available, but still I don't see the advantages of using this new type instead of the old cv::Mat.
When should I use Matx instead of Mat?
Short answer: cv::Mat uses the heap to store its data, while cv::Matx uses the stack.
A cv::Mat uses dynamic memory allocation (on the heap). This is appropriate for big matrices (like images) and lets you do things like shallow copies of a matrix, which is the default behavior of cv::Mat.
However, for the small matrices that cv::Matx is designed for, heap allocation would be very expensive compared to doing the same thing on the stack. I have seen a block of math reduce processing time by over 75% by switching to using stack-allocated types (e.g. cv::Point and cv::Matx) instead of cv::Mat.
It's about memory management and not wasting (in some cases important) memory or just reservation of memory for an object you'll use later.
That's how I understand it – may be someone else can give a better explanation.
This is a late late answer, but it is still an interesting question!
dom's answer is quite accurate, and the heap/stack reference in user1460044's is also interesting.
From a practical point of view, I wouldn't use Matx (or Vec), except if it were completely necessary. The major advantages of Matx are
Using the stack (efficient![1])
Initialization.
The problem is, at the end you will have to move your Matx data to a Mat to do most of stuff, and so, you will be back at the heap again.
On the other hand, the "cool initialization" of a Matx can be done in a normal Mat:
// Matx initialization:
Matx31f A(1.f,2.f,3.f);
// Mat initialization:
Mat B = (Mat_<float>(3,1) << 1.f, 2.f, 3.f);
Also, there is a difference in initialization (beyond the heap/stack) stuff. If you try to put 5 values into the Matx31, it will crash (runtime exception), while calling the Mat_::operator<< with 5 values will only store the first three.
[1] Efficient if your program has to create lots of matrices of less than ~10 elements. In that case use Matx matrices.
There are 2 other reasons why I prefer Matx to Mat:
Readability: people reading the code can immediately see the size of the matrices, for example:
cv::Matx34d transform = ...;
It's clear that this is a 3x4 matrix, so it contains a 3D transformation of type (R,t), where R is a rotation matrix (as opposed to say, axis-angle).
Similarly, accessing an element is more natural with transform(i,j) vs transform.at<double>(i,j).
Easy debugging. Since the elements for Matx are allocated on the stack in an array of known length, IDEs or debuggers can display the entire contents nicely when stepping through the code.