I'm building an application using OpenCL, and while running Valgrind I am seeing a bunch of warnings about various problems inside libamdocl64. I'm not so worried about them as I see many other people mentioning them too. What does worry me, however, is that Valgrind is detecting uninitialized values in
data after I do
size_t sz = /* size I'm expecting the output to be */
data = malloc(sz);
clEnqueueReadBuffer(queue, data_buf, CL_TRUE, 0, sz, data, 0, NULL, NULL);
data_buf = clCreateBuffer(context, CL_MEM_READ_WRITE | CL_MEM_HOST_READ_ONLY, /* same size as above */, NULL, NULL);
data_buf is passed as a global argument to my kernel.
Specifically, I am getting several warnings like this when using some of the values in
data (not all curiously enough):
==3176== Conditional jump or move depends on uninitialised value(s)
==3176== by 0x4057CA: ocl_main(void*) (ocl.cpp:102)
==3176== by 0x5A630A1: start_thread (in /usr/lib/libpthread-2.18.so)
==3176== by 0x5D5E49C: clone (in /usr/lib/libc-2.18.so)
==3176== Uninitialised value was created by a client request
==3176== at 0xB4B9930: subioMemCpuAccess(IODrvConnHandleTypeRec*, IODrvMemHandleTypeRec*, long long, long long, bool) (in /usr/lib/libamdocl64.so)
==3176== by 0xB4B1456: ioMemCpuAccess(void*, void*, long long, long long, _AtiDriverModule, IOMemoryUsageEnum, bool) (in /usr/lib/libamdocl64.so)
==3176== by 0xB2C907F: gsl::MemoryObject::map(gsl::gsSubCtx*, gslMapAccessTypeEnum, gslGPUMaskRec, bool, bool) (in /usr/lib/libamdocl64.so)
==3176== by 0xB25E667: CALGSLDevice::resMapRemote(void*&, unsigned long&, gsl::MemObject*, gslMapAccessTypeEnum) const (in /usr/lib/libamdocl64.so)
==3176== by 0xB24A36C: gpu::Resource::map(gpu::VirtualGPU*, unsigned int, unsigned int, unsigned int) (in /usr/lib/libamdocl64.so)
==3176== by 0xB24A470: gpu::Resource::hostRead(gpu::VirtualGPU*, void*, amd::Coord3D const&, amd::Coord3D const&, unsigned long, unsigned long) (in /usr/lib/libamdocl64.so)
==3176== by 0xB211FA9: gpu::DmaBlitManager::readMemoryStaged(gpu::Resource&, void*, gpu::Resource&, unsigned long, unsigned long&, unsigned long&, unsigned long) const (in /usr/lib/libamdocl64.so)
==3176== by 0xB2143DA: gpu::DmaBlitManager::readBuffer(gpu::Memory&, void*, amd::Coord3D const&, amd::Coord3D const&, bool) const (in /usr/lib/libamdocl64.so)
==3176== by 0xB215A17: gpu::KernelBlitManager::readBuffer(gpu::Memory&, void*, amd::Coord3D const&, amd::Coord3D const&, bool) const (in /usr/lib/libamdocl64.so)
==3176== by 0xB2521BC: gpu::VirtualGPU::submitReadMemory(amd::ReadMemoryCommand&) (in /usr/lib/libamdocl64.so)
==3176== by 0xB1E491F: amd::CommandQueue::loop(device::VirtualDevice*) (in /usr/lib/libamdocl64.so)
==3176== by 0xB1E518D: amd::CommandQueue::Thread::run(void*) (in /usr/lib/libamdocl64.so)
I'm also getting
Value8 warnings when trying to read any of the values. Because this data is then propagated throughout my application, I also get several more errors as a result of this one further down the line.
I might very well be doing something completely silly that is causing this behavior, but I cannot figure out what that might be. Has anyone seen a similar issue anywhere?
I find it particularly strange that Valgrind says the uninitialized value was created inside the OpenCL library when I'm the one malloc'ing it?
Arch Linux x64 w/Linux 3.12
There is no error in the code snippet that you have posted. Do you get desired result if you run your application outside valgrind? A simple test scenario can be writing 1s on the data_buf in the kernel and after the clEnqueueReadBuffer call with CL_TRUE in the host, check the buffer.
The clCreateBuffer call is allocating data in the device memory. I think valgrind is talking about this memory allocation and not the data that you mallocd.
Ah, perhaps I didn't explain myself correctly. The code is working perfectly fine as far as I can tell, also under Valgrind. That is not my concern. My concern is that I am getting a ton of warnings from Valgrind from within the AMD OpenCL library, which may obscure other, deeper errors. Ideally, the library should give no Valgrind errors when run with a correct application.
Check the AMD Knowledge base KB73 posting at: http://developer.amd.com/resources/documentation-articles/knowledge-base/?ID=19
The information in that posting suggests that those errors are false alarms and can be ignored.