Tuan and I took this discussion off the list, which resulted in the following patch to resolve the problem: http://reviews.m5sim.org/r/3338/ Thanks, Marc
On Tue, Feb 16, 2016 at 1:12 PM, Marc Orr <[email protected]> wrote: > Hi Tuan, > > Thanks for reporting this issue. I'd like to try and help resolve it. > > First, can you send me a bit more information, so that I can try and > reproduce the bug locally? Specifically: > > - Exact scons command to build gem5. > - In particular, I want to confirm which protocol you are using > (VIPER or RfO). > - Source for the benchmark. If it's not something you want to > distribute on the mailing list, you can send it to me directly. Also, I > think you forgot to attach the kernel file (or it didn't come through). > - Exact command to build the benchmark. > - Exact gem5 command to run the benchmark. > > Thanks, > Marc > > On Mon, Feb 15, 2016 at 3:17 PM, Tuan Ta <[email protected]> > wrote: > >> Hi all, >> >> We are using the recently uploaded gpu-compute patches to run some OpenCL >> 2.0 benchmarks in AMD SDK. >> >> When we run the SVMAtomicBinaryTreeInsert benchmark on the simulator, we >> run into an unexpected termination: >> >> gem5.opt: build/HSAIL_X86/mem/ruby/system/GPUCoalescer.cc:310: void >> GPUCoalescer::insertKernel(int, PacketPtr): Assertion >> `kernelEndList.count(wavefront_id) == 0' failed. >> Program aborted at tick 366329000 >> >> Looking closer at the simulator, we saw that when a GPUCoalescer tried to >> handle a MemFenceReq and the execution was being in the middle of an >> outstanding release (VIPERCoalescer::makeRequest() - line 99), it called >> the GPUCoalescer::insertKernel (line 112) that tried but failed to >> assert "kernelEndList.count(wavefront_id) >> == 0". A code comment in GPUCoalescer::insertKernel also mentions that the >> simulator could possibly hang in the future if the assertion is not done. >> >> Looking at the kernel and also its assembly code, we suspect that a >> memfence instruction placed near the end of the kernel caused the problem. >> >> // A snippet of source code >> do { >> ... >> if (exFlag){ >> if (child) { >> ... >> } else { >> ... >> done = 1; >> } >> atomic_compare_exchange_strong() >> } >> atomic_work_item_mem_fence() >> } while (!done); >> >> return; >> >> Please find both kernel file and its assembly code in the attachment. Our >> running configuration is: >> >> - We used apu_se.py configuration and VIPER protocol and set num_CUs to 8 >> - The Tree Insert programs adds 256 new nodes to the initial tree. No node >> is added by CPU. >> >> We think the above do-while loop makes some threads execute the kernel end >> earlier than others in a wavefront. When the coalescer executes the >> memfence and checks the list of kernel end, it may see a kernel end >> request >> already existing for the wavefront and the assertion fails. >> >> Is there any one else running into the same problem? If so, could you give >> us a hint on what caused the problem and how to fix it? >> >> Thank you! >> >> Regards, >> >> Tuan Ta >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
