00:34 imirkin: skeggsb: ok... so... the whole vbios of thing
00:34 imirkin: with the lack of pcir
00:34 imirkin: thoughts?
00:40 airlied: we should pick up the of vbios
00:40 imirkin: we do
00:40 airlied: it used to work, then again 64k pages used to do as well
00:40 imirkin: but we fail it
00:40 imirkin: because it doesn't have a PCIR
00:40 imirkin: which became required after ben reworked some of the vbios parsing stuff
00:40 imirkin: to deal with multiple vbios sections
00:40 airlied: ah oops
00:40 imirkin: or... something
00:41 imirkin: i guess that's challenge #1
00:41 imirkin: actually challenge #1 is to build a nouveau module out of ben's tree targeted at the ppc
00:52 imirkin: skeggsb: drm/nouveau/nvkm/subdev/bios/shadowof.c:46:44: error: 'struct nvkm_device' has no member named 'pdev'
00:52 imirkin: struct pci_dev *pdev = bios->subdev.device->pdev;
00:56 imirkin: skeggsb: probably want to fold this in somewhere: http://hastebin.com/owuwetuxuw.diff
00:59 imirkin: skeggsb: also, where did DRIVER_USE_AGP go? (or do i not need to worry about that)
01:00 imirkin: urgh, this thing really doesn't want to build against 4.1
01:01 imirkin: airlied: i guess you've already pulled this into your tree, but i guess you're about to get some ppc build fail (see patch above)
01:27 airlied: been a while since my ppc has built a kernel,
01:28 imirkin: yeah, just a heads-up
01:40 airlied: imirkin: fixed the first one in drm-next,
01:40 airlied: skeggsb: there is another warning in nv04_disp about nv_mask
01:41 imirkin: airlied: ah cool. i didn't get to build the whole thing as it fails against 4.1.6
01:41 imirkin: fetching your tree now
01:41 imirkin: although i should probably just leave it all to another day
01:54 imirkin: skeggsb: fwiw this is the warning i get that airlied was referring to: http://hastebin.com/bozosinoku.lua
01:57 imirkin: skeggsb: airlied: i think it needs something like this, http://hastebin.com/votimopula.diff, but i haven't checked
02:13 imirkin: skeggsb: actually i get that the "header fetch failed". it looks like it scans 4K ahead, but the vbios on my box is only 2K
03:55 airlied: bskeggs, imirkin_: I pushed a fix for the other case, I just aligned code with same code in overlay.c, it's a smaller patch
05:30 karolherbst: imirkin: I think I somehow know whats going on now, at least I know what the problem is now
05:33 karolherbst: who has some RA knowledge? I put an assert into GCRA::simplify which fails in the second RA run: "assert(this->hi.prev->next == &this->hi);"
05:34 karolherbst: I think this should never happen
08:27 xexaxo: imirkin: the lack of DRIVER_USE_AGP is ok. Ben inlined the unwrapped the drm helpers and is using the agp bits directly.
09:26 imirkin: airlied: looks good thanks
09:29 karolherbst: imirkin: and I think I found the source of the corpution, nearly there
09:33 karolherbst: at least I get the same crash with valgrind and gdb now
09:36 karolherbst: this http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp#n1422 messes with the gcra.hi list
09:36 karolherbst: removing the delete statement allows the compile to go a little further to the other issue I found with valgrind
09:37 imirkin: cleanup should probably just unset hi as well
09:37 karolherbst: nodes will be deleted in the dtor anyway
09:37 karolherbst: yeah maybe
09:37 karolherbst: maybe not
09:37 karolherbst: becuase hi is used in the next RA retry again
09:37 karolherbst: this is somehow the issue
09:37 karolherbst: first try => fails, because spilling
09:37 karolherbst: second try crashes, because of some issues inside gcra.hi
09:38 imirkin: but it seems to not unset either hi nor low
09:38 karolherbst: maybe the delete is wrong entirly
09:38 karolherbst: cleanup is called within every retry
09:38 karolherbst: but the gcra is still the same
09:38 imirkin: right.
09:39 karolherbst: now I am in the third retry and get this recordWr issue with both gdb and valgrind
09:39 karolherbst: which I only had before in valgrind
09:40 karolherbst: which makes somehow sense
09:41 karolherbst: valgrind should overwrite all *alloc and free calls and therefore the memory pages can be different, so they don't contain random garbage in valgrind
09:43 karolherbst: ohhhh
09:44 karolherbst: imirkin: I didn't removed the nodes==NULL statement and it still works
09:44 karolherbst: mhhh
09:44 imirkin: karolherbst: clean up hi/lo[]
09:44 imirkin: of perhaps when deleting the node
09:44 imirkin: it needs to remove itself from the list
09:44 imirkin: but doesn't
09:45 karolherbst: ohhh wait
09:45 karolherbst: these aren't pointers
09:45 imirkin: no, they're not
09:45 imirkin: well they sort of are
09:46 karolherbst: :D
09:46 karolherbst: no idea how to cleanup them up right then :/
09:46 imirkin: you need to set ->next == this
09:46 karolherbst: ahhh
09:46 karolherbst: and low = hi ?
09:46 karolherbst: ohh wait
09:46 karolherbst: no
09:46 karolherbst: okay
09:46 karolherbst: got it
09:47 imirkin: and prev = this
09:47 imirkin: GCRA::RIG_Node::RIG_Node() : Node(NULL), next(this), prev(this)
09:47 imirkin: basically get it back to that state
09:47 imirkin: so like hi.next = hi.prev = &hi;
09:47 imirkin: lo[0].next = lo[0].prev = &lo[0];
09:47 imirkin: etc
09:49 imirkin: and leave the delete [] nodes in the cleanup obviously
09:50 karolherbst: yeah
09:50 karolherbst: sadly it doesn't change the fact, that it crashes later
09:50 karolherbst: but it works now with the delete [] statement "somehow"
09:50 karolherbst: but it would have been too easy, if there would be only one issue anyway
09:59 karolherbst: now I have a "v->reg.data" coruption somewhere :/ *sigh*
09:59 imirkin: all that stuff is allocated on an arena, which makes it harder to find use-after-free
10:00 karolherbst: yeah, but this comes from the instruction I touched, so this could be my fault somehow now
10:01 imirkin: you could change NV50_IR_FUNC_ALLOC_OBJ_DEF and a few other things to make them regular allocations
10:01 karolherbst: to find issues easier with valgrind?
10:01 imirkin: and NV50_IR_PROG_ALLOC_OBJ_DEF
10:01 imirkin: yea
10:02 karolherbst: nice
10:02 imirkin: you'll probably have to touch up the ->release* calls too
10:02 imirkin: bbl
11:48 hakzsam: imirkin, gmail doesn't want to send the patch 4/4 of my series... strange!
11:48 hakzsam: if you want you can have a look here http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvc0_queries_cleanup
11:53 imirkin_: hakzsam: i don't super care about any of that stuff -- feel free to push
11:54 karolherbst: ohh nice, my /home partition was mounted ro ...
11:55 hakzsam: imirkin_, okay, I'll push in the next few days
12:31 karolherbst: what does the rcp instruction do?
12:32 imirkin_: 1/x
12:32 imirkin_: aka reciprocal
12:32 karolherbst: I see
12:32 imirkin_: rsq = 1/sqrt(x)
12:33 karolherbst: because I see some changes in my binaries between runs, though never anything serious
12:34 karolherbst: 3: rcp f32 $r1 $r0 (8) 4: pinterp mul f32 $r0 a[0x0] $r1 (8) 5: pinterp mul f32 $r1 a[0x4] $r1 (8) vs...
12:34 karolherbst: 3: rcp f32 $r0 $r0 (8) 4: pinterp mul f32 $r1 a[0x4] $r0 (8) 5: pinterp mul f32 $r0 a[0x0] $r0 (8)
12:34 karolherbst: should be the same result, shouldn't it?
12:34 imirkin_: ya
12:34 imirkin_: weird that the RA picks diff things
12:34 karolherbst: it still bothers me, that its different sometimes
12:34 karolherbst: yeah
12:34 imirkin_: perhaps there's non-determinism in RA
12:34 karolherbst: usually it doesn't
12:35 imirkin_: might do a randomized approach to graph coloring
12:35 imirkin_: i honestly have never looked at those details
12:35 imirkin_: i don't even know if it tries to do graph coloring in the first place
12:35 imirkin_: that's just what i did way back when
12:35 imirkin_: back in antiquity :)
12:36 karolherbst: it don't happen when I don't change the order
12:36 karolherbst: *doesn't
12:36 karolherbst: there are some "color" fields, so I think it does
12:37 imirkin_: coloring is an NP-hard problem
12:37 imirkin_: but there are lots of good approximations
12:37 imirkin_: [do you know what coloring is?]
12:38 karolherbst: mhh I know what red-black trees are
12:38 imirkin_: hehehe
12:38 karolherbst: if that's somehow the same?
12:38 imirkin_: not the same
12:38 karolherbst: :D
12:38 karolherbst: I see
12:38 imirkin_: do you know what a graph is?
12:38 karolherbst: yeah
12:38 imirkin_: https://en.wikipedia.org/wiki/Graph_coloring
12:38 imirkin_: i'm lazy. go read that :)
12:39 karolherbst: ohh
12:39 karolherbst: I think I've got it
12:39 imirkin_: each node is a value
12:39 imirkin_: and nodes are connected if the values have to be live at the same time
12:39 imirkin_: and then you create a coloring, and each color = a register
12:40 karolherbst: like you find to try the smallest numbers of colors needed, so that each node isn't connected with one with the same color?
12:40 imirkin_: and then if you need more colors than there are registers, you do spilling
12:40 imirkin_: which basically creates cuts in the interference graph
12:40 karolherbst: ohh, okay
12:40 imirkin_: by splitting the live interval of the value
12:40 karolherbst: what are %r..t regs by the way?
12:41 imirkin_: before regalloc
12:41 imirkin_: they just have sequentially increasing numbers so that they're different
12:41 imirkin_: regalloc then converts them to $rN which are real numbered registers
12:41 imirkin_: the diff is id < 0 or id > 0 iirc
12:41 karolherbst: I see
12:42 karolherbst: its still strange, that when I change the order a bit, that the RA becomes undeterministic
12:42 imirkin_: well, the RA is based on that graph
12:42 imirkin_: if you change the graph, then it will do different things :)
12:42 karolherbst: yeah I know, but currently I produce the same instruction order every run
12:43 imirkin_: the coloring algo could have randomness in it
12:43 imirkin_: i'm nto sure
12:43 karolherbst: but why doesn't it occur, when I don't reorder?
12:43 imirkin_: luck?
12:43 karolherbst: mhh
12:43 imirkin_: or something that you're missing
12:43 karolherbst: yeah
12:43 karolherbst: that kind of bothers me
12:43 karolherbst: because usually everything is fine despite that spilling issue
12:45 karolherbst: ohhhh
12:45 karolherbst: mhh
12:47 karolherbst: I was wrong, I really change the order different between runs sometimes... but I don't get why
12:49 karolherbst: mhhhh
12:58 karolherbst: imirkin_: what can be sources of randomness despite uninitialized values and pseude random generators?
12:59 karolherbst: *pseudo
12:59 imirkin_: 'despite'?
12:59 imirkin_: those 2 things are the things.
12:59 karolherbst: ohhh
12:59 karolherbst: except
12:59 karolherbst: I meant like hw based
12:59 imirkin_: no.
13:03 karolherbst: ohh malloc-fill and free-fill :D didn't see those args before
13:10 karolherbst: I should use scan-build more often :D
13:11 karolherbst: "../../../../../src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c:702:33: warning: The left operand of '!=' is a garbage value"
13:14 imirkin_: probably not.
13:15 karolherbst: mhhh, there are some things, maybe there is something usefull
13:16 imirkin_: if(src[0].swz[NVFX_SWZ_X] != NVFX_SWZ_X)
13:16 imirkin_: so yeah... there's no way the compiler can prove that it's a non-garbage value
13:16 imirkin_: but... it's fine :)
13:17 karolherbst: mhhh
13:17 karolherbst: depends
13:17 karolherbst: scan-build usually tells you, that there is a possible way, there might be garbage
13:18 imirkin_: well, tucked in a variable for loop, under a condition, you have
13:18 imirkin_: src[i] = tgsi_src(fpc, fsrc);
13:18 karolherbst: there is a nice html file which may show me the way
13:18 imirkin_: right
13:18 imirkin_: and that way is practically impossible
13:19 imirkin_: but the compiler can't know that
13:19 karolherbst: mhh, wait
13:19 karolherbst: both for loops directly false
13:20 imirkin_: right
13:20 imirkin_: if there are no src's, then it'll be garbage
13:20 imirkin_: but a SCS instruction will always have srcs :)
13:20 karolherbst: :)
13:20 karolherbst: I see
13:21 karolherbst: its static analysis, so it doesn't know whats there at runtime ;)
13:21 imirkin_: right.
13:21 imirkin_: like i said, it can't happen, but the compiler can't prove it.
13:21 karolherbst: but it can help to find stupid issues like that :D
13:21 karolherbst: ahh you meant it that way, right
13:21 imirkin_: coverity runs over mesa regularly
13:22 imirkin_: you can contact vinson lee if you want to be added to the account
13:22 karolherbst: ohh its fine
13:24 karolherbst: there is a lot of stuff inside codegen /nv50_ir_from_tgsi.cpp, but seems also a lot of such implicit thingies
13:24 karolherbst: will check if it would have found the one issue from today
13:28 karolherbst: sadly no :/
13:59 karolherbst: mhhh
13:59 karolherbst: imirkin_: found it
13:59 karolherbst: I am iterating over std::tr1::unordered_set<ValueRef *>
13:59 karolherbst: that's why the order is changing sometimes
13:59 imirkin_: make it a custom hash
13:59 imirkin_: oh, this is for spilling?
14:00 imirkin_: annoying
14:00 karolherbst: no
14:00 imirkin_: yeah, use a custom hash, i hate non-determinism
14:00 karolherbst: just result
14:01 karolherbst: you wanted to use unordered_sets :p
14:01 imirkin_: yeah, but you can hash on the i
14:01 imirkin_: id*
14:01 imirkin_: which shoudl be determinsitic
14:01 karolherbst: yeah
14:02 karolherbst: I think I will do a typedef with a custom hasher instead of this std::hash overloading stupid thing
14:08 karolherbst: mhhh
14:08 karolherbst: this is a pitty
14:08 karolherbst: imirkin_: how can I tell ValueRefs are equal or not?
14:08 karolherbst: except by ptr value
14:09 imirkin_: look at the value they ref?
14:09 karolherbst: and if they don't have any?
14:09 imirkin_: although i guess there's additional stuff
14:09 imirkin_: hrmph
14:09 imirkin_: annoying.
14:09 karolherbst: :D
14:09 karolherbst: kind a
14:09 imirkin_: ok screw it
14:09 imirkin_: why are you storing ValueRef's btw?
14:09 karolherbst: mhh
14:10 karolherbst: value ptr + 1000* id?
14:10 imirkin_: those are instruction-specific
14:10 karolherbst: I don't store them
14:10 karolherbst: I iterate over the defs
14:10 karolherbst: to find new schedulable instructions
14:10 imirkin_: ahhhh
14:10 imirkin_: and the instruction contains it as a set
14:10 imirkin_: ok.
14:10 karolherbst: yeah
14:10 karolherbst: will do the ptr + constant * id thingy
14:10 karolherbst: just to try it out
14:11 imirkin_: no, that won't work
14:11 imirkin_: don't do tha
14:11 karolherbst: ... :(
14:11 karolherbst: k
14:12 karolherbst: at least I have an explenation for the difference in order, but that shouldn't matter later
14:12 karolherbst: I could also just ignore the spilling issue and just schedule a bit more intelligent
14:12 karolherbst: then this should also just go away :D
14:13 imirkin_: the spilling issue is probably pre-existing
14:13 karolherbst: mhhh
14:14 karolherbst: now it didn't crash for one run
14:15 karolherbst: ohh reg.data is an union
14:16 karolherbst: and always contains "0x3fffffff" on crash
14:24 karolherbst: imirkin_: some knowledge about Program::emitBinary ?
14:24 karolherbst: because this crash happens in postra
14:26 imirkin_: that performs the linkage i think?
14:26 imirkin_: or is it the thing that calls the code emitter?
14:27 karolherbst: yeah
14:27 karolherbst: the latter
14:27 imirkin_: ok
14:27 imirkin_: that's just something to serialise the nv50 ir into smoething that the gpu will understand
14:27 imirkin_: i.e. encode the instructions using the proper format
14:27 karolherbst: the crash happens inside SchedDataCalculator::visit
14:27 imirkin_: right, so for kepler+
14:28 imirkin_: there's something called "sched data"
14:28 karolherbst: I don't know when the coruption happens though
14:28 imirkin_: which is basically a pseudo-instruction every 8th opcode
14:28 imirkin_: which providse various information to the gpu about latencies and whatnot
14:28 imirkin_: so that it knows to be able to schedule other SM's or... something.
14:28 karolherbst: yeah
14:29 imirkin_: but basically if you get it right, you get more perf :)
14:29 karolherbst: I figured as much
14:31 karolherbst: okay, its already broken in visit :/
14:43 karolherbst: okay, it happens somewhere iside prog->registerAllocation() for sure though :/
14:58 karolherbst: ......
14:58 karolherbst: not again
14:58 karolherbst: imirkin_: its cleanup again :/
15:02 imirkin_: you need to also reset the node poniter i think
15:02 imirkin_: and maybe a couple other things
15:03 karolherbst: okay ....
15:03 karolherbst: nope
15:03 karolherbst: different issue
15:03 karolherbst: you will love it
15:04 karolherbst: this line: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp#n1715
15:05 karolherbst: turns -1 into 1073741823
15:05 imirkin_: you're right -- i love it
15:05 karolherbst: :D
15:05 imirkin_: ok so
15:05 imirkin_: clearly that shouldn't be -1
15:05 imirkin_: so... wtf
15:06 karolherbst: there are -1 values all along, didn't mind much about them though
15:06 karolherbst: ohh wait
15:06 imirkin_: idToBytes is v->reg.data.id * MIN2(v->reg.size, 4);
15:06 karolherbst: sometimes -1 is turned into 0
15:06 imirkin_: if id is -1, then that's bad.
15:07 karolherbst: okay, there shouldn't be any -1
15:14 karolherbst: ohhh mhhh
15:14 karolherbst: mhhh
15:15 karolherbst: now I am confused
15:15 karolherbst: if id is -1
15:15 karolherbst: and v->reg.size something sane, like 4
15:16 karolherbst: then shouldn't the id be -4?
15:17 imirkin_: sooooooooo
15:17 imirkin_: i dunno what this is doing
15:18 imirkin_: but i don't think anything i suspposed to be negative in there in the first place
15:18 karolherbst: yeah
15:18 imirkin_: this is probably for assigned registers, which are all >= 0
15:18 karolherbst: right
15:18 karolherbst: GCRA::selectRegisters is filling it
15:18 imirkin_: and it's for dealing with register widths and whatnot
15:18 imirkin_: which can be 2, 4, 8, 12, or 16
15:19 imirkin_: (2 only on nv50 btw... half-registers)
15:19 karolherbst: this fuction is huge :/
15:19 karolherbst: huge in the sense of some loops and stuff
15:19 karolherbst: wow, we are lucky
15:19 karolherbst: the first big loop doesn't do it directly
15:20 karolherbst: there is this
15:20 karolherbst: lval->reg.data.id = regs.unitsToId(nodes[i].f, nodes[i].reg, lval->reg.size);
15:21 imirkin_: so it only gets called on success
15:21 imirkin_: which means that everything got RA'd
15:21 imirkin_: which means there should be no -1's
15:21 imirkin_: this is where the join fun begins
15:21 imirkin_: when 2 values are coalesced
15:21 karolherbst: mhhh
15:21 imirkin_: they are "joined"
15:21 imirkin_: i.e. one points to another
15:21 karolherbst: yeah, found it
15:21 karolherbst: if (nodes[i].reg >= 0 && nodes[i].colors > 0)
15:22 imirkin_: so one value will have join == this
15:22 imirkin_: while all the others will have join == that
15:22 imirkin_: :)
15:22 karolherbst: this is wrong, then the data stays -1
15:22 karolherbst: ohh
15:22 karolherbst: okay
15:22 imirkin_: [i forget how it keeps track of offset from the base... something clever i'm sure]
15:22 imirkin_: [i think it looks at the argument number in the merge/split
15:23 karolherbst: I really don't want to debug the entire nodes[i].reg and nodes[i].colors thing ...
15:23 karolherbst: sounds bad and like a lot of time
15:23 imirkin_: ;)
15:23 imirkin_: now you know why i stay away from it
15:24 karolherbst: but I bet reg is something strange and not colors
15:24 imirkin_: wwwwwait a minute
15:24 imirkin_: / TODO: check if modifying Instruction::join here breaks anything
15:24 karolherbst: :D
15:24 imirkin_: i think that may be the issue
15:24 imirkin_: dunno
15:24 karolherbst: will treat them as fixed?
15:24 karolherbst: ohh
15:24 karolherbst: already do
15:25 imirkin_: well, you shouldn't be
15:27 karolherbst: how I enable the REG_ALLOC debug thingies?
15:27 imirkin_: NV50_PROG_DEBUG=255
15:27 imirkin_: (there's some bit for it, but... meh. i just enable ti all)
15:28 karolherbst: the thing just is, that sometimes it doesn't crash
15:28 karolherbst: but simply returns -4 (which just means failed RA)
15:30 karolherbst: oh wow, how that more debug output doesn't help :/ at least there is no -1
15:32 karolherbst: okay
15:32 karolherbst: colors is indeed always set
15:32 karolherbst: reg is the strange bit
15:34 karolherbst: mhhh
15:34 karolherbst: well
15:34 karolherbst: I think it doesn't checks right if the pass failed
15:34 karolherbst: because if it doesn't crash, the part isn't reached at all
15:34 karolherbst: RegAlloc done: 0
15:35 karolherbst: nv50_ir_generate_code: ret = -4
15:38 karolherbst: yeah
15:38 karolherbst: I think that's it
15:38 imirkin_: ?
15:38 karolherbst: just iterate over all ids now and return false when id -1 after GCRA::selectRegisters
15:39 imirkin_: heh
15:39 imirkin_: but that means there's some sort of fail
15:39 imirkin_: it shouldn't be -1
15:39 imirkin_: i.e. a logical fail
15:39 karolherbst: it doesn't have enough regs I guess
15:39 imirkin_: no, it does
15:39 imirkin_: otherwise coloring would have failed
15:40 karolherbst: ohhh
15:40 karolherbst: wait
15:40 karolherbst: color has to be above 0?
15:40 karolherbst: ohh it is
15:40 karolherbst: its usually 1
15:42 karolherbst: ...
15:42 karolherbst: now I somehow think having -1 there isn't as bad usually
15:42 karolherbst: because that's usually the case
15:48 karolherbst: ohh wait, not true entirely
15:48 karolherbst: I think they get handled later? don't know
16:37 karolherbst: imirkin_: what are these nops inside the TESS_EVAL shader?
16:38 karolherbst: :D
16:38 imirkin_: nop is when something uses an undefined value
16:38 imirkin_: this can be both legitimate and a bug
16:38 imirkin_: so it's just a dummy definition
16:38 karolherbst: mhh
16:39 imirkin_: which allows ssa to work
16:39 imirkin_: e.g. you might have like
16:39 imirkin_: int x;
16:39 imirkin_: if (foo) x = 5;
16:39 karolherbst: I see
16:39 karolherbst: because the tess shader look strange in heaven
16:40 imirkin_: in general, or with your pass?
16:40 karolherbst: my pass
16:40 imirkin_: you might be missing some fun dep
16:40 karolherbst: the shader looks also strange after it
16:40 karolherbst: yeah
16:40 karolherbst: seems so
16:40 imirkin_: tess stuff is crazy
16:40 imirkin_: and highly multi-dimensional :)
16:40 imirkin_: a lot of 2d inputs/outputs
16:40 karolherbst: https://gist.github.com/karolherbst/9710e75e2671ecb1d931
16:40 karolherbst: the nops are going crazy
16:41 imirkin_: oh, it's for stupid stuff like
16:41 imirkin_: gl_Position.xyz = bla
16:41 imirkin_: and then nobody ever defines .w
16:41 imirkin_: but we write a w
16:41 imirkin_: so... what should we write :)
16:42 imirkin_: hmmmmm
16:42 imirkin_: this is a bit more worrying
16:42 karolherbst: if I disable tess while running heaven, everything looks good
16:42 imirkin_: 3: nop - # %r463 (0)
16:42 imirkin_: wtf does this even mean
16:43 imirkin_: i think some pass is doing something funky
16:43 imirkin_: ohhh... it might be the interference stuff
16:43 imirkin_: yeah
16:43 imirkin_: it's to mark %r463 as used
16:43 imirkin_: so that the RA doesn't think to assign the same reg to a dest
16:43 imirkin_: since it gets overwritten
16:44 imirkin_: and the instructino dies
16:44 karolherbst: mhh
16:44 imirkin_: that was a fun little bug
16:44 imirkin_: bbl
16:45 karolherbst: anyway I get strange artefacts so I guess this shader is somehow wrong :/
16:45 karolherbst: ohh well
16:45 karolherbst: there are other tess shaders as well
16:52 karolherbst: mhh when I treat the NOPs as fixed, I don't get any artifects, at least
16:57 imirkin_: how do you reorder them normally?
16:57 imirkin_: ideally they'd come right after the defining instruction
17:04 karolherbst: the link has the "wrong" order
17:04 karolherbst: second half is after my changes
17:05 imirkin_: ah yes.
17:05 imirkin_: the dependencies just aren't encoded in such a way
17:05 imirkin_: yeah, basically those nops have to be attached to the instruction preceding them
17:05 karolherbst: mhh
17:05 imirkin_: they're not real... just little RA helpers
17:06 karolherbst: so if next is NOP I have to insert it right away?
17:06 imirkin_: you may consider trying to run your thing BEFORE they get inserted
17:06 karolherbst: ohh I see
17:06 karolherbst: mhh
17:06 imirkin_: but yeah... you could just schedule all NOPs first
17:06 imirkin_: bbl