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