00:40steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1432167120833216574/snapshot.jpg?ex=69001111&is=68febf91&hm=38ad6204c5b2b9ab6fd66ef0810e0463bf18d0a88e16a92cd6fd5b576e0294af&
00:40steel01[d]: gfxstrand[d]: Well... it... tries now. Then blows up pretty spectacularly.
00:40steel01[d]: 10-26 23:36:00.192 0 0 E : [ C0] nouveau 17000000.gpu: fifo: fault 01 [WRITE] at 0000000002920000 engine 00 [gr] client 0f [GPC0/PROP_0] reason 00 [PDE] on channel 3 [0082d9c000 BootAnimation[2359]]
00:40steel01[d]: 10-26 23:36:00.209 0 0 E : [ C0] nouveau 17000000.gpu: fifo:000000:0003:[BootAnimation[2359]] rc scheduled
00:40steel01[d]: 10-26 23:36:00.217 0 0 E : [ C0] nouveau 17000000.gpu: fifo:000000: rc scheduled
00:40steel01[d]: 10-26 23:36:00.224 10 10 E nouveau 17000000.gpu: fifo:000000:0003:0003:[BootAnimation[2359]] errored - disabling channel
00:40steel01[d]: 10-26 23:36:00.234 10 10 W nouveau 17000000.gpu: BootAnimation[2348]: channel 3 killed!
00:40steel01[d]: 10-26 23:35:59.533 2348 2359 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb400003000000000 in tid 2359 (BootAnimation), pid 2348 (bootanimation)
00:41gfxstrand[d]: Heh. I may be able to look more tomorrow. Not sure if I'm actually going to the office, though, or not and my TX1 is at the office.
00:42steel01[d]: Sure, no worries.
00:44gfxstrand[d]: I did a big refactor today and might have broken stuff
00:45steel01[d]: Yeah, I was trying to read the diff and all the renames made it difficult.
00:45gfxstrand[d]: On Tegra, it's now using both kernel drivers at the same time and using the Tegra driver for linear images and Nouveau for tiled.
00:46steel01[d]: Mmm. So the tegra display hardware doesn't have the restriction that nouveau does? Interesting.
00:49gfxstrand[d]: In theory, we should be able to use either. But NGL needs tiled images to come from nouveau because of issues in the driver. And I was hoping that mapped Tegra buffers might not have the issues that mapped Nouveau buffers do.
09:19asdqueerfromeu[d]: steel01[d]: Why is the MiniGBM not `_mesa` (instead of `_nouveau`)?
13:15gfxstrand[d]: asdqueerfromeu[d]: It's a different back-end per-hardware
13:57gfxstrand[d]: Anyone looking at maintenance10?
14:23mohamexiety[d]: used to but wont be able to continue for a while
14:33gfxstrand[d]: no worries
15:27monchihuisui: I had already implemented the quantum computer specification, but there is no traces about this in my computer that you intrude into and biuld viruses to. I can solve all the fields medal conjectures too as side effect of being undreamed (by a random troll) talented/intelligent and smart, but i do not want to deal with trolls nor violators, i have no such interests in life. The
15:27monchihuisui: specification works fully , because it is built with being aware of all the mathematics and physics. So these people that are aware of the named alike also know how to do it anyhow, and there are pleanty of those living their dream life like me. I need no public or gray mass attention over this.
15:30gfxstrand[d]: I've about got maintenance10 typed
16:04lassebq: Lmao I had a kernel panic last boot and nouveau almost fully preserved framebuffer after reset, which made me think it panicked again
19:35mhenning[d]: If anyone wants to test a possible perf improvement, I'm curious if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38083 makes a measurable difference anywhere
20:56gfxstrand[d]: maintenance10 landed
21:04x512[m]: Do somebody know a brief description what each Vulkan maintenance extension does?
21:09gfxstrand[d]: https://docs.vulkan.org/features/latest/features/proposals/VK_KHR_maintenance10.html
21:09rhed0x[d]: maintenance 10 optionally allows DS<->color copies on compute and transfer
21:10HdkR: The documentation is short and sweet as usual :)
21:10gfxstrand[d]: The proposal docs are actually somewhat useful
21:10gfxstrand[d]: But docs for maintenance extensions are often pretty meh
21:17leftmostcat[d]: I stumbled on https://gitlab.freedesktop.org/mesa/mesa/-/issues/14153 and it seems relatively straightforward. Is there anything I'm missing? Would this be a reasonable place to start digging into nak?
21:20gfxstrand[d]: leftmostcat[d]: Sure! `uadd_sat` is almost trivial. It can be done without extending NAK in any interesting way. You just need to add code to `nak/from_nir.rs` for the opcode and set the bit in the `nir_shader_compiler_info` that enables it. NIR should do the rest.
21:21gfxstrand[d]: For `iadd_sat`, the implementation that NVIDIA uses requires a new form of `OpPLop` which we'll have to figure out how we want to model in NAK and then plumb into each of the back-ends.
21:22gfxstrand[d]: It's actually a really good starter task to give you an excuse to touch each of the pieces just a little in a fairly contained way.
21:23leftmostcat[d]: Great, thanks! I'll start working on it, then.
21:24gfxstrand[d]: Feel free to ask here if you have any questions, Mel, Karol, or myself should be able to give pointers.
21:27leftmostcat[d]: I appreciate the help.
22:03leftmostcat[d]: Is `uadd_sat` already implemented but maybe not advertised? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/from_nir.rs#L1647
22:08mhenning[d]: looks like they're both implemented and advertised https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26535
22:10mhenning[d]: or, uadd_sat and usub_sat that is
22:10mhenning[d]: so we're still missing iadd_sat
22:12leftmostcat[d]: Well, that MR at least gives me a few more clues as to what bits to twiddle. 🙂
22:13gfxstrand[d]: mhenning[d]: Right. I forgot about that. 😂
22:13gfxstrand[d]: I think I implemented it because `nir_lower_io.c` used to use it for some things