01:30DavidHeidelberg: karolherbst: Tiger Lake in CI looks pretty good: Pass: 4195, Fail: 23, Crash: 5, Skip: 82, Duration: 2:59
01:36DavidHeidelberg: https://gitlab.freedesktop.org/dh/mesa/-/jobs/59430428
03:33kode54: the only problem with netconsole is that I need another machine to listen for the packets
03:33kode54: only free machine I have currently is my router, and that's running opnsense, which is freebsd
03:34kode54: I only have one linux machine on the network
03:35kode54: all the rest of the desktops are Macs
03:35dwfreed: netconsole is just a UDP stream
03:35dwfreed: *anything* can receive it
03:35kode54: oh
03:35kode54: it's just a raw UDP text stream?
03:35dwfreed: yes
03:35kode54: then I can just make anything listen to it
03:36kode54: thanks, brain fart on my part
03:36kode54: I'll see if I can cook up netcat to listen for this
03:36dwfreed: socat is better :)
03:37kode54: oh, socat? hmm
04:49bbhtt: trying to build NVK on 24.1 fails with this https://dpaste.com/F2UM7FXBX
04:49kode54: how do I make socat flush to a file on every packet?
04:49kode54: it's buffering at least 2048 bytes
04:59dwfreed: it's probably stdlib buffering, not socat
04:59dwfreed: try using stdbuf to override
08:01bbhtt: The problem was that libdrm was built without nouveau, but removing that header from `src/nouveau/vulkan/nvk_cmd_buffer.c` also seems to work.
08:02bbhtt: I don't see anything using that there so I assume it is some leftover
08:21DavidHeidelberg: bbhtt: nice finding! drop MR, if I'll not get merged, at least the problem gets addressed (by build system requiring libdrm_nouveau)
08:21kode54: dwfreed: I'm attempting to use something different, in case it's useful
08:21kode54: kdumpst
08:21kode54: if anything happens again, I'll see if this is able to log
08:53bbhtt: DavidHeidelberg: ok forwarded the patch.
08:54bbhtt: This came up because we build libdrm without any backends and build mesa against core libdrm.
08:55bbhtt: the drivers are allowed to break forward or backward abi but not libdrm.so in any direction.
09:07karolherbst: DavidHeidelberg: yeah.. though I kinda prefer wiring up the CL CTS, but that's going to be quite a bit of more work
16:47FL4SHK[m]: would *like* to support some form of OpenGL or something
16:47FL4SHK[m]: I'm not sure that'll happen though
16:48FL4SHK[m]: I've been writing a software 3D renderer to figure out all the algorithms
16:48FL4SHK[m]:uploaded an image: (8KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/zQtyhxlQfsKRydYKnQSHSxCX/1000006483.png >
16:49FL4SHK[m]: got it to render this triangle today
16:49FL4SHK[m]: it's all fixed point arithmetic based for now
16:49FL4SHK[m]: but I want to make an FPGA-based floating point unit too
17:10DavidHeidelberg: karolherbst: step by step, I remember the script you sent me for the OpenCL-CTS, maybe we can do some change to the suite, so it'll integrate more nicely