01:10 redsheep[d]: gfxstrand[d]: Is this your nak/sm50 branch? Is the latest code there? I might have somebody with pascal poke at it and see if it's functional there
01:11 gfxstrand[d]: I haven't pushed in a bit but yeah
01:15 gfxstrand[d]: Pushed
01:15 redsheep[d]: Perfect, thanks
03:33 gfxstrand[d]: I think `isetp.x` is just useless on SM50
04:54 gfxstrand[d]: Nope, just very, very funky
05:45 redsheep[d]: Something seems to have regressed with zink+nvk with the plasma 6.1.3 x11 session. Applications are running with llvmpipe instead of zink. Wayland is just where it was, black screen with a mouse, and nothing else.
05:50 HdkR: If your mesa build is older than 5 hours then there was a nasty regression over the last week that was just resolved
05:50 HdkR: Well, theoretically resolved
05:51 HdkR: Still has a behaviour change that I'm no GLX expert to know if matters
05:57 redsheep[d]: I built 76ae27ef two hours ago
06:01 HdkR: welp
06:01 redsheep[d]: Ah, yeah even when I am running an nvc0 session I am seeing that NOUVEAU_USE_ZINK=1 is causing applications to go to llvmpipe
06:01 redsheep[d]: I suspect that airlied[d] will want to be aware of that ^
16:01 karolherbst[d]: `kernel: __vm_enough_memory: pid: 2310, comm: gnome-shell, bytes: 136553893888 not enough memory for the allocation` :blobcatnotlikethis:
16:02 karolherbst[d]: is there a place in nouveau where we could end up with such huge memory allocations?
16:03 karolherbst[d]: but it feels like a memory corruption or something fishy going on
16:03 karolherbst[d]: `136553893888 == 0x1fcb3f1000` which kinda looks like a pointer or something
16:36 gfxstrand[d]: karolherbst[d]: I'm hitting an issue on Maxwell where I have a `sync` that jumps to an `exit` and then seems to just walk past it. Does this sound familiar?
16:43 gfxstrand[d]: Could be something else but my fault is definitely inside my shader area
16:44 gfxstrand[d]: But it's like a page into my shader area which is weird
16:45 gfxstrand[d]: If it was just walking past the end, I'd think it would fault faster
16:45 gfxstrand[d]: :frog_thinking:
16:47 karolherbst[d]: gfxstrand[d]: uhh... not sure.. what happens if you just right before the exit?
16:47 karolherbst[d]:however
16:48 karolherbst[d]: I think I've seen shaders where nvidia added jumps past the exit to jump back to the exit
16:48 karolherbst[d]: I might misremember
16:48 karolherbst[d]: gfxstrand[d]: SM50 https://gist.github.com/karolherbst/9daca902965099ebab74b91cc37fc61c
16:49 karolherbst[d]: though those `NOP` there are also weird...
16:50 gfxstrand[d]: That's an infinite loop, though, isn't it?
16:50 karolherbst[d]: yeah.... I think so
16:51 karolherbst[d]: I've removed the `if` in my code and now it looks like this: https://gist.githubusercontent.com/karolherbst/89bc471fb318f65888befea769ebcb67/raw/d438097e4809e1cbb76c4c48a79d84e3dd2223b9/gistfile1.txt
16:51 karolherbst[d]: the `NOP` before those `EXIT` are also suspicious
16:51 karolherbst[d]: mhh
16:52 karolherbst[d]: maybe the infinite loop helps the prefetcher or something silly?
16:52 gfxstrand[d]: It could be that exit wants to always be at the end of a bundle
16:52 karolherbst[d]: possibly
16:52 karolherbst[d]: but that's not the case in the first example
16:55 karolherbst[d]: but anyway, I'm not aware myself of anything funky going on, just that nvidia is doing a couple of things which we aren't in mesa
16:56 karolherbst[d]: mhh, let me try to cook up a shader if divergency
16:58 karolherbst[d]: ehh wait..
16:58 karolherbst[d]: I think that code was generated because I told nvidia to disable all ops :ferrisUpsideDown:
16:58 karolherbst[d]: *optimizations
16:59 karolherbst[d]: ahh no, it's there anyway
17:00 karolherbst[d]: gfxstrand[d]: I think the reality is, that nvidia won't converge if you jump into an exit anyway
17:01 karolherbst[d]: because at that point it doesn't matter
17:01 karolherbst[d]: so nvidia just wouldn't hit this path ever (probably)
17:01 karolherbst[d]: so maybe there is an issue with the hardware, or something funky going on, but it doesn't matter, because we probably wouldn't get nvidias stack to ever generate such code
17:03 karolherbst[d]: a bit complex code, but here you see it as well: https://gist.githubusercontent.com/karolherbst/b0d61883f344e89bcdd74f29b521d13c/raw/7309bd4101842073cc0ea21d8a715ace85aacddc/gistfile1.txt
17:04 karolherbst[d]: `/*0148*/ @!P0 EXIT ;` within the first sync section
17:05 karolherbst[d]: with `-0` nvidia generates a `PBK` + `@P0 BRK` instead
17:06 karolherbst[d]: same as the above, just -O0 https://gist.github.com/karolherbst/50330a5755fac2c7847cbb9a48ead8a8
17:31 gfxstrand[d]: Looping at the end doesn't fix anything
17:51 gfxstrand[d]: It's also possible something is screwing up an offset calculation somewhere
17:52 karolherbst[d]: potentially
17:54 gfxstrand[d]: What's iadd.po?
17:55 karolherbst[d]: good question...
17:55 karolherbst[d]: gfxstrand[d]: do you know which bit enables/disables that?
17:56 karolherbst[d]: _could_ be a positive/negative thing, but...
17:56 karolherbst[d]: but I suspect it's something special
18:04 gfxstrand[d]: It's what you get when you try to set both ineg modifiers
18:06 gfxstrand[d]: On Turing, setting too many negate bits just throws an illegal encoding. On Maxwell, it silently means something you don't want. 🤡
18:08 gfxstrand[d]: Turns out exit had nothing to do with it. I was getting a BS address calculation in the shader thanks to iadd2
18:08 gfxstrand[d]: woo
18:08 gfxstrand[d]: Why did it end up inside my instruction area? IDK
18:10 gfxstrand[d]: Now I want to fuzz and find out what `iadd.po` does. 😅
18:10 gfxstrand[d]: Maybe it's `|x + y|` or something like that?
18:21 gfxstrand[d]: 10% run: `Pass: 113349, Fail: 49, Crash: 48, Skip: 160743, Timeout: 2, Flake: 2, Duration: 15:51, Remaining: 0`
18:28 karolherbst[d]: gfxstrand[d]: mhhh
18:32 karolherbst[d]: nvidia uses `i2i` for that one...
18:36 karolherbst[d]: gfxstrand[d]: + 1
18:36 karolherbst[d]: probably
18:37 karolherbst[d]: at least CUDA docs on `vmad` say "The plus one mode (.po) computes (a*b) + c + 1, which is used in computing averages. Source operands may not be negated in .po mode."
19:32 gfxstrand[d]: Oh, that makes sense actually
20:26 redsheep[d]: gfxstrand[d]: That's much faster than the last 10% run you posted as well, very nice
20:39 gfxstrand[d]: It's not crashing and hanging like mad