CODEWITHSUNDEEP
c++macosopencl
luxchar
luxchar

Reputation: 625

OpenCL (unexpectedly) freezes when trying to run kernel code

Well, I've tried asking on the Apple developer forums but no one responded. I thought that stackoverflow would be more appropriate. Here it is...

I have some OpenCL kernel that runs through pixels stored in a frame buffer object, and counts non-black and non-white pixels. It used to run fine on my machine, but I believe that updates to Mac OS X and/or devtools might have caused a problem to cause it stall.

The kernel object associated with the kernel code is attached to a QT window, and the kernel code is run n-times when the window requires an render update. This window is updated twice after it is created initially, which means that the sequence of openCL code does not cause problems initially. When I bring the window to the foreground, it requires another update and attempts to run the kernel code another n-times. But in the middle of those n-times, it stalls. i.e. if it needs to run 51 times, it stalls at iteration 26. It appears that a call to clEnqueueReadBuffer causes a stall.

I'm going to leave out details about why I use the openCL code unless it's absolutely necessary since that might confuse people. I thought it would be good to focus on the OpenCL code itself. Here it is for reference: http://dl.dropbox.com/u/10838242/forumsquestion.cpp

Here's the gdb backtrace:

#0  0x00007fff8e3a6122 in __psynch_mutexwait ()
#1  0x00007fff8955ad9d in pthread_mutex_lock ()
#2  0x000000010dd3acbd in gldFlushQueue ()
#3  0x000000010bbc193f in IOAccelContextFinishResourceSysMem ()    
#4  0x000000010bbcd5b0 in gpumAcquireFenceOnQueue ()
#5  0x000000010dd43fcd in gldCopyBufferDataWithQueue ()
#6  0x00007fff8ffa7e2e in GCC_except_table49 ()
#7  0x00007fff8ffc5f11 in clFinish ()
#8  0x00007fff936800b6 in _dispatch_client_callout ()
#9  0x00007fff93681723 in _dispatch_barrier_sync_f_invoke ()
#10 0x00007fff8ffc5ddb in clFinish ()
#11 0x00007fff8ffc25c2 in clSetEventCallback ()
#12 0x00007fff8ffb86e6 in clEnqueueReadBuffer ()
#13 0x0000000100020a31 in CLHandler::update (this=0x107683e20, tagged=@0x7fff5fbfb960, w=761, h=711) at clhandler.cpp:343
#14 0x000000010002f8c1 in CustomBladesGLWidget::render (this=0x1072b09e0, indexMode=true, offset=135288, numPnts=4416, blobID=25, bladeIdsIntersected=@0x7fff5fbfb960) at customBladesGLWidget.cpp:943

In the attached file, line 343 (bold above) corresponds to this call (in function CLHandler::update):

//read data from buffer
status = clEnqueueReadBuffer(cqueue,hitbuffer,CL_TRUE,0,mNumBladeCells * sizeof(float),mBladesHit,0, NULL,&event);
handleError("clEnqueueReadBuffer","",status);

Now, if I were to comment everything BELOW the initial call to clEnqueueWriteBuffer, it would stall at that function call instead. I have no idea why this occurs. It's not like I'm trying to use a mutex or anything. Any help is greatly appreciated.

System specs: MacbookPro 8,2, Core i7 2.2 GHz, AMD Radeon HD 6750M, OS X 10.8.2.

Thanks

Upvotes: 1

Views: 1405

Answers (2)

Eric Bainville
Eric Bainville

Reputation: 9906

There should be a call to glFinish before the first OpenCL API call using GL objects, and a clFinish after the last one. Weaker options (i.e. calling Flush instead of Finish) may work on specific platforms.

See the OpenCL 1.2 extension specification, section 9.7.6.1.

Update. Specifically on the Apple platform, the fastest option is to call glFlushRenderApple before the first OpenCL call, and clFinish after the last one.

Upvotes: 1

alariq
alariq

Reputation: 496

Why are you passing event to clEnqueueWriteBuffer/clEnqueueReadBuffer if you state that it is blocking write (3rd parameter is true)? You also do not need any calls to clWaitForEvents(1, &event) for this reason.

Instead, i would add event to clEnqueueNDRangeKernel. and wait for it after clFlush(). Because clFlush only triggers execution but gives no guarantee that after its call all previously queued commands will be finished (unlike clFinish). And only then call clEnqueueReleaseGLObjects. But your case also should be ok, as soon as your queue was not created with CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE flag.

Also can you specify what exact lines gets commented/uncommented?

Upvotes: 0

Related Questions