10:06karolherbst: anholt: btw, I will plug in my nvac and do a deqp run to see if I may hit the same error in dmesg or not
10:06karolherbst: I looked at the bug and I am sure something super annoying is going on
10:07karolherbst: ehh wait.. I just realized, that's nvac, not nvca
10:24karolherbst: ehh.. let me use another GPU as this one spams my dmesg with AER messages
10:25karolherbst: anholt: btw, I have a script which merges _all_ CTS tests across all the sub binaries and runs them all together, in case you are interested
10:29karolherbst: ahh.. and my nva0 doesn't get recognized if it's not the main GPU wtf
10:29karolherbst: those tesla era GPUs are really a pita
10:34karolherbst: of course it works in the non main PCIe slot :D
10:36karolherbst: ehh nva0 is only GLES 3.0?
10:37karolherbst: looks intentional
10:37karolherbst: imirkin: anything the nva0 can't do for gles3.1? Or just not tested?
10:40karolherbst: seems like my nva8 (not nvac) doesn't spam in the second slot either, good
10:40karolherbst: "[128/97366] Pass: 110 Fail: 0 Skip: 18 ExpectedFail: 0 UnexpectedPass: 0 Crash: 0 Timeout: 0 Missing: 0 Flake: 0 Duration: 8 Remaining: 1:41:18" let's see how long it takes :D
11:52karolherbst: heh "Illegal character in test case names"
11:54karolherbst: ahh found it
12:18karolherbst: oh wow.. building the CTS in release mode speeds it up by quite a lot
13:39karolherbst: "[99652/99652] Pass: 85849 Fail: 990 Skip: 12738 ExpectedFail: 0 UnexpectedPass: 0 Crash: 2 Timeout: 4 Missing: 0 Flake: 69 Duration: 1:10:17 Remaining: 0" and no invalid opcode :(
13:58imirkin: karolherbst: nva0 can't do plenty
13:58imirkin: nva8 should be fine though
14:01imirkin: nva0 is missing shared atomics iirc
14:01imirkin: but also it's missing all the DX10.1 features
14:01imirkin: like gather, query lod
14:01imirkin: and another one that i'm not thinking of
14:10imirkin: (i assume you mean nva0 aka G200)
14:12karolherbst: yeah I meant nva0
14:13imirkin: the G200 has some fp64 support btw
14:14imirkin: i tried to hook it up at some point, but that effort failed for some reason. i don't remember why.
14:14imirkin: could be due to missing sqrt & co
14:14imirkin: but iirc i had trouble with even more basic things
14:14imirkin: since i only ever played around with it remotely for a brief period, i let it sink
14:15imirkin: not a ton of them out there, even fewer running nouveau, and who gives a shit about fp64. but thought i'd mention it :)
14:16imirkin: the "invalid opcode" thing from the recent bug isn't really an invalid opcode
14:16imirkin: that's not an opcode we would ever generate
14:16karolherbst: yeah... I noticed that
14:16karolherbst: I assume it's just invalid bits?
14:16imirkin: i figured it might be pushbuf corruption
14:16imirkin: but it's also not a pushbuf command we'd ever generate
14:16karolherbst: it's not?
14:16imirkin: it's not.
14:17imirkin: 3b0, while a valid command, would also have a size.
14:17imirkin: which would be reflected by some other bits set
14:17karolherbst: I thought you meant that 15e0 mthd
14:17imirkin: not to mention a non-0 subchannel
14:17imirkin: oh. no. that's just a "GO" method
14:17imirkin: which is what runs the shaders/etc
14:17imirkin: so all errors are attributed to it
14:18karolherbst: subchannel 3 is the correct one
14:18imirkin: was i reading the pushbuf wrong?
14:18karolherbst: 3D is 0 on nvc0+ and 3 on nv50
14:18imirkin: NV50_FIFO_PKHDR(int subc, int mthd, unsigned size)
14:18imirkin: return 0x00000000 | (size << 18) | (subc << 13) | mthd;
14:18imirkin: and the value was 0x3b0
14:18imirkin: so neither subc nor size were set
14:18imirkin: nvc0 shifts the method over by 2 bits
14:18imirkin: but not before
14:19imirkin: nvc0+ has a diff pushbuf format
14:19karolherbst: imirkin: keep in mind, that the user might not run with asserts enabled
14:19karolherbst: and we might just fall through
14:19imirkin: well i couldn't see an obvious way for that to be generated
14:19imirkin: but i also didn't look that long
14:20imirkin: i'm gonna stop looking at nouveau stuff in the very near future
14:20imirkin: will send email tonight
14:20karolherbst: it's probably something super annoying
14:20karolherbst: sad to hear, but okay
14:20imirkin: i thought that was implied with the nir move, no?
14:20imirkin: pretty sure i mentioned it, but wtvr
14:20karolherbst: it was, but also not the first time you said something like that
14:20imirkin: i might still look at some display things
14:21imirkin: but probably nothing mesa-related
14:21imirkin: still a bit curious about those 4:2:0 modes
14:21karolherbst: ahh yeah, that would be helpful, especially now that we do support HBR3
14:22karolherbst: although I guess with HBR3 nobody would really hit it
14:22karolherbst: imirkin: ever looked into DSC?
16:05anholt: karolherbst: runing all cts tests across all the binaries is what deqp-runner suite support is for. check out the *.tomls in the Mesa tree.
16:07karolherbst: ahh, cool, didn't know about that
18:19karolherbst: imirkin: soo.. I checked what CUDA says about G200 and that one claims that G200 > everything else
18:20karolherbst: guess I might try it out when I get bored