Hi,
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 code. 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. Any help is greatly appreciated.
If this problem is indicative of something more problematic then I guess Apple support might be one option. System specs: MacbookPro 8,2, Core i7 2.2 GHz, AMD Radeon HD 6750M, OS X 10.8.2.
Thanks
0 comments:
Post a Comment