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
