Hi Michael and Tony,
I tried to assign individual register space to each wavefront to increase the number of active wavefronts per SIMD unit. Therefore, GPU can switch the schedule to another ready wavefront when the current one gets into stall status. However, I got the null pointer because the memstate cannot find the virtual space through lookup call in page walk TLB stage. This error was raised by the one wavefront gains the incorrect virtual space and the "fixupFault" could not find that address within the virtual memory space list and did not fix it. Michael, I found your "lazy physical page allocation" commit changed the virtual memory mapping. This error was gone when I set the wavefront slot number per SIMD to 1, but that is different from the real machine. Do you have any thoughts regarding this error, Michael? Tsung Tai 1372255724303: system.l3_tlb: Doing a page walk for address 0x7ffee93cb000 1372255760321: system.cpu2.CUs.wavefronts3: CU0: WF[1][1]: wave[135] Executing inst: flat_load_dword v0, v[2:3] (pc: 0x7ffee9284440; seqNum: 38814) 1372255760321: system.cpu2.CUs.wavefronts3: CU0: WF[1][1]: wave[135] (pc: 0x7ffee9284448) 1372255760988: system.cpu2.CUs.wavefronts3: CU0: WF[1][1]: wave[135] Executing inst: s_waitcnt vmcnt(0) & lgkmcnt(0) (pc: 0x7ffee9284448; seqNum: 38815) 1372255760988: system.cpu2.CUs.wavefronts3: CU0: WF[1][1]: wave[135] (pc: 0x7ffee928444c) 1372255803009: system.l3_tlb: Doing a page walk for address 0x4e5db000 1372255803009: global: pTable LOOKUP FAIL[0x4e5db392], fixupFault:0 1372255803009: system.l3_tlb: NULL PageWalk address 0x4e5db000 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
