I guess first, to confirm, I need to ask is s_getpc_b64 basically something like grabbing the instruction pointer, and s_setpc_b64 setting the instruction pointer? I can guess the s_sub_b32 and s_subb_b32....it looks like its getting the instruction pointer (pc=program counter?), subtracting from it, and setting it to implement a jump? If so, what are the unit's associated with the pc?
The details: We have a kernel that when running in a loop hangs the GPU. We have other functions running in loops, so clearly its not something as basic as that. Upon looking at a simplified function's disassembly, we come to the part about updating the loop counter, all is well. It compares, then jumps. When it jumps, it goes to a location where it writes some debug output to ram, then the curious part, the s_getpc_b64 sub, subb, and s_setpc_b64. Worse, the value being subtracted is 0x16940, which is more than the number of lines in the disassembly. It would make sense if it were jumping to an offset likely in the FFFFF000 range that it would hang. I tried 16940/4, but that puts it in the middle of one of the functions called by the loop, and not the first one either. /2 and it would still go negative. We're at a loss here for whats going on.
The new driver causes it to hang all the time. We're reinstalling it to see if we get the same getpc and setpc stuff going on, and I'm probably going to upgrade my box to 12.2 because I remember having some sort of issue I posed on here about with the preview2 and 3 drivers.....I want to think it caused all my kernels to hang, but I don't remember.