02:58 imirkin: skeggsb: i think you have an oopsie...
02:58 imirkin: + switch (nvkm_rd32(device, 0x614300 + soff) & 0x00300000) {
02:58 imirkin: + case 0x00000000:
02:58 imirkin: + case 0x00030000:
03:00 imirkin: either the mask of the switch values are wrong, in case it's not immediately apparent
03:12 imirkin: skeggsb: also i can't imagine this doing too much good:
03:12 imirkin: u32 pu_pc = (seqctl & 0x0000000f) >> 8;
04:11 skeggsb: imirkin: oops, i think i forgot to pull the fixed patch from my testbox before pushing
04:11 skeggsb: thanks
14:54 imirkin: hakzsam: are you SURE those are plain neg modifiers?
14:54 imirkin: hakzsam: i think it's just the high bits
14:55 imirkin: i.e. what happens if the immed is 1, and you set that modifier
14:55 imirkin: do you get -1
14:55 imirkin: or do you get something else?
14:55 imirkin: (taking about the integer variants, obviously)
15:02 hakzsam: imirkin, http://hastebin.com/uriwopogoj.avrasm
15:03 imirkin: gr, i hate thinking. give me a minute
15:03 imirkin: er, right, yeah. so it's not a sign bit.
15:03 imirkin: it's just "all the high bits"
15:03 imirkin: i.e. that is really representing 0xfff80001
15:05 hakzsam: nvdisasm output is confusing
15:05 imirkin: a little, at first.
15:06 imirkin: remember, they're not magicians, and they're lazy just like us - so keep in mind that there's underlying code which works with some form of table, to generate the output you see
15:06 hakzsam: yeah
15:10 imirkin: skeggsb: ok, new version looks good. or at least not as obviously bad :)
17:17 Yoshimo: Direct firmware load for nvidia/gm204/fecs_inst.bin failed with error -2 , what does error -2 mean in this case?
17:17 Yoshimo: the file seems to exist, is it broken?
17:17 imirkin_: #define ENOENT 2 /* No such file or directory */
17:18 imirkin_: i guess it doesn't exist as much as you think it does?
17:19 Yoshimo: for me that looked like a clear symlink to the gm200 version but maybe it is damaged
17:19 imirkin_: maybe it's not there at the time that nouveau loads?
18:27 austriancoder: is there already a handy tool to compare different draw calls using rnndb files for register desc?
18:28 imirkin_: i hear diff is good
18:30 imirkin_: i.e. you pipe each one through something that does lookups with rnndb
18:30 imirkin_: and then diff the results
18:30 austriancoder: imirkin_: soso... diff :)
18:31 imirkin_: rob wrote something nice with cffdump, which keeps track of everything written before a draw call
18:31 imirkin_: and then dumps out all the state when he sees a draw call
18:31 imirkin_: which makes it easier to diff
18:31 austriancoder: yeah.. that could be what I am looking for
18:31 austriancoder: thx
18:32 imirkin_: (for freedreno, obv)
18:33 austriancoder:has some wired hand written qt based app, which does something like that without rnndb knowledge and I am not quite happy with it
18:33 imirkin_: austriancoder: https://github.com/freedreno/freedreno/blob/master/util/cffdump.c
18:33 Yoshimo: how complete is that btw? I guess it won't drive android phones ever, will it?
18:34 imirkin_: Yoshimo: https://plus.google.com/u/0/111524780435806926688/posts/fkQ1BMjNNcn
19:15 imirkin_: austriancoder: in nouveau, we also have tools that parse the output of valgrind-mmt and present them in nice ways with the help of rnndb
19:15 imirkin_: austriancoder: basically you definitely want some tool that ran read your traces and process them against rnndb
19:16 austriancoder: yeah... doing it by hand sucks