Does OpenCL always always initialize device memory?

I noticed that often, the global and constant memory is initialized to 0. Is this a universal rule? I could not find anything in the standard .

+8
opencl
source share
2 answers

No no. For example, I had this small kernel for testing atomic add:

 kernel void atomicAdd(volatile global int *result){ atomic_add(&result[0], 1); } 

Call this host code (pyopencl + unittest):

 def test_atomic_add(self): NDRange = (4, 4) result = np.zeros(1, dtype=np.int32) out_buf = cl.Buffer(self.ctx, self.mf.WRITE_ONLY, size=result.nbytes) self.prog.atomicAdd(self.queue, NDRange, NDRange, out_buf) cl.enqueue_copy(self.queue, result, out_buf).wait() self.assertEqual(result, 16) 

always returned the correct value when using my processor. However, on the ATI HD 5450, the return value was always undesirable.

And if I remember well, on NVIDIA the first launch returned the correct value, that is 16, but for the next run the values ​​were 32, 48, etc. It was a reuse of the same location with the old value still stored there.

When I fixed the host code with this line (copying the value 0 to the buffer):

 out_buf = cl.Buffer(self.ctx, self.mf.WRITE_ONLY | self.mf.COPY_HOST_PTR, hostbuf=result) 

Everything works fine on any devices.

+9
source share

As far as I know, there is no sentence in the standard that says this. Some driver implementations may do this automatically, but you will not rely on it.

I remember that once I had a case when the buffer was not initialized to 0, but I can not remember the "OS + driver" settings.

What is likely to happen is that a typical OS does not use even 1% of today's device memory. Therefore, when you start OpenCL, there is a high probability that you will fall into an empty zone.

+1
source share

All Articles