00:32RSpliet: karolherbst (and me): https://paste.fedoraproject.org/paste/~IOi3k5rEHP2GX--oeS~3w
00:38karolherbst: RSpliet: right now I am investigating why flattening doesn't completly worked.. as this seems to reduce the preassure on the stack :/
00:41RSpliet: Sure. Well, here's the ASM on my GM107, which looks like it corresponds pretty well with the output you shared
00:41RSpliet: All the syncs and branches are still there
00:42karolherbst: the limit hit
00:42karolherbst: but a different block with the same amount of instruction was fine
00:42karolherbst: uff isConstantCondition
00:43karolherbst: why is that there?
00:43karolherbst: imirkin: ?
00:43karolherbst: why do we reduce the limit for flattening if the predicate compares against a constant
00:44karolherbst: RSpliet: hah, it doesn't fix it in this case
00:44karolherbst: but the shader is a little simplier now
00:46karolherbst: RSpliet: https://gist.githubusercontent.com/karolherbst/464600985b3b84ffdcdcf54daae2a3d5/raw/911e3b786a075313f5866fee3902aa00d427fa90/gistfile1.txt
00:46karolherbst: now we have 0 joins :)
00:47RSpliet: and still failure?
00:48karolherbst: doesn't seem to change anything
00:48karolherbst: even the same amount of traps
00:48karolherbst: or similiar
00:48karolherbst: that's never constant in the first place
00:48RSpliet: that leaves the pairing of the bra with the break as the only suspect
00:48karolherbst: which might also be an indicator that something funky is going on
00:50karolherbst: mhh, I am currently wondering if I really want to go through the pain and do an mmt trace and see what nvidia does
00:51karolherbst: but that would be for tomorrow
00:51karolherbst: RSpliet: anyway, I am convinced that we don't do anything wrong
00:51karolherbst: we just have to enable the off-chip stack
00:54karolherbst: or maybe we really have to sync on each iteration, but the nvidia generated shader would tell us
01:02karolherbst: nvidia has probably some silly and fast emulator which tells them in 1us if they have to enable the stack or at which loop to sync to prevent that :p
01:04karolherbst: HdkR: you know what always bothers me? That people can just use their information they got under NDA in other companies as long as stuff doesn't get open sourced.. but just telling open source project won't do, because it's under NDA ...
01:05HdkR: It's super frustrating
01:06HdkR: Once you know the nuances of the CRS it becomes a heck of a lot easier to manage as well
01:12karolherbst: I am convinced that if an inner loop diverges you want to sync on each iteration in the outer loop... that's the only solution which would require a non insane cause
17:10orbea: anyone have an idea about this xorg failure with nouveau and mesa-19.1.1? It was reported by someone else on the Slackware forum. http://dpaste.com/1YW1V0J.txt
18:32karolherbst: " Illegal instruction at address 0xb64c2df7"?!?
18:32karolherbst: something is wrong with your binaries
18:32karolherbst: most likely
18:33orbea: they could of screwed up something on their install, thanks for the feedback
18:33karolherbst: yeah.. dunno
18:33karolherbst: the modules look fine from the log
18:33karolherbst: might be something really odd
18:43karolherbst: mhh, valgrind-mmt doesn't seem to work with 430: mmaptrace: ../../mmt/mmt_trace.c:167 (__verify_state): Assertion 'neg1->start < neg2->start || neg1->start >= neg2->end' failed.
18:46karolherbst: unknown type: 0x4e :/
19:05karolherbst: rhyskidd, mwk: my mmt log ends like this, any idea what to do? https://gist.githubusercontent.com/karolherbst/087d1d0dfe598ca56a2c632446b003a3/raw/43bb7bc361381e962bb76f6a7d7971bd2f569219/gistfile1.txt
21:14karolherbst: this looks like a bug inside mmt