02:10 fdobridge: <r​edsheep> So, I figured out a better way to test the plasma wayland issue and I have finally gotten a useful backtrace that might finally help fix that session
02:10 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1245559816781303870/info.txt?ex=66593179&is=6657dff9&hm=c56587c1a7d16eae0da15e575e2f24be4cc073203bf32ca76856ecddf64ad613&
02:10 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1245559817280684032/gdb.txt?ex=66593179&is=6657dff9&hm=7fd17887d61b79ed8f7d3778f9631ab615273bdb17fac8cedc343588cff4be4f&
02:10 fdobridge: <r​edsheep> This second attachment is a full backtrace from vkcube crashing in libvulkan_nouveau.so while attempting to launch on the wayland session
02:12 fdobridge: <g​fxstrand> How is the swapchain null?!?
02:13 fdobridge: <g​fxstrand> That seems very unlikely to be an NVK bug.
02:14 fdobridge: <g​fxstrand> Maybe the swapchain is failing to create for some reason?
02:14 fdobridge: <r​edsheep> Application bug, or zink bug then? Or kernel?
02:15 fdobridge: <r​edsheep> Is there anything else that would be useful for me to get from gdb or another application that would make for a better test case?
02:23 fdobridge: <r​edsheep> Maybe a trace from some part of the session start will be more illuminating
02:35 fdobridge: <a​irlied> build vkcube from scratch and debug it maybe?
02:51 fdobridge: <r​edsheep> Would that help in terms of getting debug symbols in here to see more detail? It's not just vkcube-wayland, everything fails to launch, with the weird exception of the plasma overview effect
02:54 fdobridge: <a​irlied> it would let you debug it 🙂
02:55 fdobridge: <a​irlied> at least trace where the null swapchain is coming from
04:49 fdobridge: <S​id> oh shit freedesktop gitlab is going to be down for 2 days
04:49 fdobridge: <S​id> starting june 3rd (monday)
04:49 dviola: bummer
04:50 fdobridge: <S​id> https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/1341
04:53 fdobridge: <S​id> honestly looking forward to the upgrade
04:53 fdobridge: <S​id> "But given that our db is 90% CI, this split should hopefully speed up the instance quite a bit by having normal operations handled on a much smaller db."
12:24 fdobridge: <S​id> is there any specific mesa MR/branch that could use some testing right now?
12:57 fdobridge: <a​huillet> are there maybe games that you own not on the game tracker yet?
12:59 fdobridge: <S​id> oh those are plenty e-e
12:59 fdobridge: <S​id> I own ~570 games
12:59 fdobridge: <S​id> something's definitely odd though.. I launched steam and my session froze entirely, had to force a reboot
13:00 fdobridge: <S​id> gonna try again on the latest -rc kernel (since I've been on faith's NVK branch)
13:03 fdobridge: <S​id> my session doesn't even run on nvk/zink, so I do not know why the freeze happened
13:04 fdobridge: <m​arysaka> @tiredchiku for mesh shader, the rebase requires quite a lot of work (that's before shader object support), I will have to dig that when I return from holiday
13:04 fdobridge: <S​id> no worries, no rush :saigeheart:
13:04 fdobridge: <S​id> I just kinda wanna try throwing Alan Wake 2 at it :myy_TinyGiggle:
13:05 fdobridge: <m​arysaka> It's not complete so unlikely to work anyway, task shaders are disabled too
13:30 fdobridge: <S​id> :tiredkitty:
13:30 fdobridge: <S​id> I'll test tomorrow.. I'll set up a CI to build me an -rc kernel so I don't have to punish my laptop as much anymore
13:56 fdobridge: <r​edsheep> I had that yesterday, did that show up in dmesg? I recall a weird error I'd never seen before
13:57 fdobridge: <S​id> no idea
13:57 fdobridge: <S​id> don't have my tailscale network set up atm, so couldn't ssh in
13:59 fdobridge: <r​edsheep> It seems like the bindless ubo branch got some stuff working which could be interesting to test
14:00 fdobridge: <S​id> on faith's fork, yes?
14:05 fdobridge: <r​edsheep> From her mesa branches, yeah. And I'm still on her kernel using your pkgbuild
14:07 fdobridge: <S​id> dunno if I want to stay on that kernel or move to 6.10 rc
14:08 fdobridge: <r​edsheep> Rebasing the relevant patches to 6.10 would be nice, if like to test 6.10 once it is on rc2
14:08 fdobridge: <r​edsheep> I don't like to test rc1, I'm not *quite* that crazy
14:10 fdobridge: <S​id> I'm pretty sure faith's kernel has patches backported into them
14:10 fdobridge: <S​id> and there's some patches that haven't gone into the kernel yet/on the wya
14:11 fdobridge: <S​id> s\/wya/way
14:11 fdobridge: <r​edsheep> I don't think all of them have gotten into 6.10, yeah
14:15 fdobridge: <r​edsheep> I'm sure it would be in your journal, it was for me. The error mentioned nouveau
14:16 fdobridge: <S​id> oh, yup
14:16 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1245742709801488465/trace.txt?ex=6659dbce&is=66588a4e&hm=5403db52459371353069ca3d5789e34c929fec7681b89ad9a2e3a79170bcd6a8&
14:18 fdobridge: <r​edsheep> Oh I didn't have a kernel rip, maybe multiple issues surrounding steam right now then
14:19 fdobridge: <p​ixelcluster> kernel rip :D
14:19 fdobridge: <S​id> it probably doesn't help I'm on the steam beta client either
14:19 fdobridge: <S​id> anyway, kernel rip means more fun for me
14:21 fdobridge: <S​id> I kiiinda wanna run rc and try to symlink in 555 GSP too
14:21 fdobridge: <S​id> just to see what happens
14:22 fdobridge: <S​id> I don't think the kernel checksums the GSP before loading it, and my session runs on intel
14:22 fdobridge: <S​id> what could go wrong :wolfFIRE:
14:24 fdobridge: <S​id> for now I think I'll just update my copy of faith's kernel and switch to -rc tomorrow
14:25 fdobridge: <S​id> and investigate that kernel rip only if I observe it happen there too
14:44 fdobridge: <p​ac85> x86's instruction pointer
14:44 fdobridge: <a​huillet> someone is in a good mood... :)
14:44 fdobridge: <a​huillet> someone is in a good mood... :) (the emojis) (edited)
14:44 fdobridge: <r​edsheep> I might have gone overboard
14:51 fdobridge: <p​ixelcluster> amd64's instruction pointer
14:51 fdobridge: <p​ixelcluster> https://media.discordapp.net/attachments/925855860557746267/1014285080971186216/IMG_4929.gif
14:52 fdobridge: <p​ac85> Lol
15:08 fdobridge: <!​DodoNVK (she) 🇱🇹> %eip is the x86-32 one
15:27 fdobridge: <g​fxstrand> @karolherbst What do those magic docs have to say about dependencies between uniform and warp instructions?
15:27 fdobridge: <g​fxstrand> I've got 2-3 more big bugs to sort out with uniform and that's one of them.
15:27 fdobridge: <g​fxstrand> `Pass: 1193387, Fail: 1564, Crash: 27554, Skip: 1519391, Timeout: 8, Flake: 25, Duration: 4:03:38, Remaining: 0`
15:28 fdobridge: <g​fxstrand> That's last night's run with VERY aggressive use of uniform instructions.
15:29 fdobridge: <k​arolherbst> I think there are higher latencies involved, but I'd have to figure that all out, because that's not easy to expplain
15:30 fdobridge: <g​fxstrand> *sigh*
15:31 fdobridge: <k​arolherbst> but it depends
15:32 fdobridge: <k​arolherbst> like a normal ALU reading the uniform register written by uldc/umov is fast, written by other U* ops it's not
15:32 fdobridge: <k​arolherbst> and then an even longer wait is needed for others
15:33 fdobridge: <k​arolherbst> all the needed waits are heavily simplified in codegen and even nak
15:33 fdobridge: <k​arolherbst> the reality is way more complex
15:34 fdobridge: <k​arolherbst> like the latencies depend on what kind of instruction reads and what has written it and so on
15:34 fdobridge: <k​arolherbst> so I could certainly answer it for specific cases, but not generally
15:39 fdobridge: <g​fxstrand> That makes sense. UMOV isn't really a uniform op. ULDC is funky, too.
15:53 fdobridge: <r​edsheep> I keep seeing mention of ldc here, but searching for it seems to yield nothing useful. I assume you're not talking about lens distortion correction...
15:56 fdobridge: <g​fxstrand> load constant
15:58 fdobridge: <m​ohamexiety> https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#nvidia-ampere-gpu-and-ada-instruction-set doesn't have semantics sadly but you can find it in this table here
16:12 fdobridge: <r​edsheep> This isn't expected to be a comprehensive list, right? I see no bvh instructions
16:13 fdobridge: <m​ohamexiety> I don't think they publicize RT stuff anywhere sadly (although they could also have their things internally organized in a way that RT isn't part of the ISA?)
16:13 fdobridge: <g​fxstrand> No, it's not comprehensive. There are a few ray-tracing instructions that aren't publicly documented anywhere but it's close
17:41 fdobridge: <!​DodoNVK (she) 🇱🇹> How are you going to fix 27k crashes?
17:43 fdobridge: <r​edsheep> Considering the context and how many tests there are that many issues actually seems pretty low of instruction latencies are sometimes wrong
17:49 fdobridge: <r​edsheep> So, I just had a thought and I want to make sure I understand right.
17:49 fdobridge: <r​edsheep>
17:49 fdobridge: <r​edsheep> NAK isn't really just a shader compiler, right? It's a backend compiler for nir, and therefore entirely fixed function rendering code also flows through it?
17:50 fdobridge: <r​edsheep> I'm trying to understand if all this performance stuff will affect trivial cases where you're just drawing some triangles, like vkcube kind of basic, or even simpler
18:16 fdobridge: <g​fxstrand> Probably about 10k at a time.
22:28 fdobridge: <a​irlied> @redsheep NAK is just a shader compiler for NIR shaders, NIR has frontends including from SPIR-V and GLSL. Mesa also generates NIR shaders for older GL APIs that didn't use shaders
22:28 fdobridge: <a​irlied> vkcube triangles use shaders directly
22:29 fdobridge: <r​edsheep> Ah okay, thanks for clearing that up.
23:37 fdobridge: <g​fxstrand> I may need to figure out R2P