On Tue, Jun 30, 2015 at 1:53 AM, Ilia Mirkin <[email protected]> wrote: > On Thu, Jun 25, 2015 at 10:41 AM, Ilia Mirkin <[email protected]> wrote: >> Hello, >> >> We recently tracked down a bug on Tesla GPUs (i.e. G80-GT218) whereby >> it appears that instructions like >> >> 00000028: b5000409 08000780 add rn f32 $r2 $r2 neg c0[$a1] >> 00000040: b500060d 08004780 add rn f32 $r3 $r3 neg c0[$a1+0x4] >> >> or with nvdisasm: >> >> .headerflags @"EF_CUDA_SM12 EF_CUDA_PTX_SM(EF_CUDA_SM12)" >> /*0000*/ FADD R2, R2, -c[0x0][A1+0x0]; /* >> 0x08000780b5000409 */ >> /*0008*/ FADD R3, R3, -c[0x0][A1+0x1]; /* >> 0x08004780b500060d */ >> >> don't appear to execute properly. However just MOV'ing the values into >> registers works fine. This was observed on a G92 chip. See bug >> https://bugs.freedesktop.org/show_bug.cgi?id=91056. >> >> I was hoping you could save me some time and let me know what >> instructions can load things like c0[$a1+4] (or maybe it's only in >> combination with the modifier?), and which Tesla-family GPU's have >> those restrictions. > > Hm, there's something more subtle going on here. Please disregard. A > simple shader on my GT215 for both vertex and fragment demonstrates > that those instructions work at least some of the time. (I didn't have > a nv50-era card plugged in when I was asking the question, so I > couldn't check for myself.) Perhaps there's something more subtle > going on here, like non-uniformity across execution units...
Just to close the loop on this one, turns out our code emission was just plain wrong. The IR was asking for c0[$a1], but were really emitting c0[0] when it was in the third position of a mad instruction. Oops! -ilia _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
